-
Notifications
You must be signed in to change notification settings - Fork 7.9k
pgsqlSetNoticeCallback #4823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pgsqlSetNoticeCallback #4823
Conversation
@yohgaki, could you please check this? |
php#4823 (comment) Closure cannot be used as a callback if not persisted.
Fix to what @ranvis noted in php#4823 (comment)
Fix to what @ranvis noticed in php#4823 (comment)
This should not go into 7.4 either as you say @cmb69 |
@ranvis, @cmb69, @derickr: thank you for your feedback. |
Allows a callback to be triggered on every notice sent by PostgreSQL. Such notices can be sent with a RAISE NOTICE in PL/pgSQL; in a long running stored procedure, they prove useful as realtime checkpoint indicators.
Add a test for a standard pgsqlSetNoticeCallback use.
php#4823 (comment) Closure cannot be used as a callback if not persisted.
Move callback cleanup to a separate function.
Fix to what @ranvis noted in php#4823 (comment)
Fix to what @ranvis noticed in php#4823 (comment)
The PostgreSQL-provided message was zvaled and not freed.
Discard non-null result of callback.
Core dumped when using a string callable.
# Prise en compte de php/php-src#4823 (comment) = On essaie de faire converger les modifs sur PHP 7 et leur report en PHP 5. darcs-hash:e027eb266470eaf8f8ea4bb6df11295f9b2f555b
It seems this patch addresses known NOTICE shortcoming. I cannot be sure if it addresses all shortcomings. |
@yohgaki: to be honest, I would say that we could obtain more details using PQsetNoticeReceiver instead of PQsetNoticeProcessor. Maybe dissociate the level and the message, get the call stack *… But I think this could be studied in a second time, without breaking what has been done here: even if reimplementing on PQsetNoticeReceiver, the message would still be passed as the first callback param (after all, it's the main thing we're interested in); and details would go into additional, optional parameters of the callback. * Incidentally, the only locations where I found info on those hypothetical additional fields are PHP pgsql's doc (https://www.php.net/manual/pgsql.constants.php, look for pg_result_error_field()) and Symfony's code (https://github.com/symfony/var-dumper/blob/master/Caster/PgSqlCaster.php) |
(that said, I would be honored if you could find the time to review this iteration of the enhancement, @yohgaki) |
php#4823 (comment) Closure cannot be used as a callback if not persisted.
Superseded by #6764 (which targets master). |
php#4823 (comment) Closure cannot be used as a callback if not persisted.
php#4823 (comment) Closure cannot be used as a callback if not persisted.
php#4823 (comment) Closure cannot be used as a callback if not persisted.
php#4823 (comment) Closure cannot be used as a callback if not persisted.
php#4823 (comment) Closure cannot be used as a callback if not persisted.
php#4823 (comment) Closure cannot be used as a callback if not persisted.
Allows a callback to be triggered on every notice sent by PostgreSQL.
Such notices can be sent with a RAISE NOTICE in PL/pgSQL; in a long running
stored procedure, they prove useful as realtime checkpoint indicators.