pgsqlSetNoticeCallback

[outtersg]

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.

Originally proposed at https://bugs.php.net/78621

[driesvints]

@outtersg you might want to rebase here so the PR can be merged. The appveyor build also seems to fail.

[outtersg]

@outtersg you might want to rebase here so the PR can be merged. The appveyor build also seems to fail.

Thanks @driesvints for mentionning it… I did not even noticed I wasn't notified of my own PR's status changes.

[HellLeaf]

Is this PR still active?

[outtersg]

@HellLeaf wrote:

Is this PR still active?

Yes, I ensure it still compiles (with PHP 8.1.2);
and it still proves really useful in a production environment where PHP launches long PL/pgsql stored procedures.

[devnexen]

Sorry for the long reply, could you possibly rebase against the current master please ? thanks.

[outtersg]

@devnexen wrote:

Sorry for the long reply, could you possibly rebase against the current master please ? thanks.

And here it is;
by the way, the CI spotted an approximation I did on the generated _arginfo.h, so long live the CI!
(and thank you for showing interest to this PR from so far away in time!)

[devnexen]

Thanks I ll have a look later this week, at first glance looking good.

[devnexen]

Looking good but will wait a bit before merging.

[nielsdos]

Some things about the code don't seem 100% right. Please also test this with a Closure object and a trampoline.

[outtersg]

Thank you @nielsdos for your invaluable review! I started this as an amateur quick way of implementing my need, with zero knowledge of the PHP coding best practices (and in fact no intelligence at all in the code: most of it is a big copy-paste-adapt of some other ext where I found callback use, from a PHP 5.3 source tree). So your detailed review with tips on exactly how to converge to a clean solution is really welcome for the newby I am here.

I'm wondering with your:

Please also test this with a Closure object and a trampoline.

that I'm not familiar at all with. Would you please point me to a test sample of a trampoline callback I could elaborate upon?

I'll try to digest and apply all you recommendations, but it will take me some time (and probably many IC failures) before something polished emerges here.

[nielsdos]

that I'm not familiar at all with. Would you please point me to a test sample of a trampoline callback I could elaborate upon?

Please see

php-src/ext/sqlite3/tests/sqlite3_trampoline_setauthorizer_no_leak.phpt

Line 8 in b80faeb

class TrampolineTest {

When you have a class with the __call magic function, you can create a "trampoline" by creating a callable to any name that is not a method already on the class. E.g. on line 18 of that test, a callable to the authorizer function of that class is made which will implicitly call the __call function. Internally this kind of callable is known as a trampoline because the engine needs an extra step.

The commit that added the test also has some code for the "F" ZPP modifier.

I'll try to digest and apply all you recommendations, but it will take me some time (and probably many IC failures) before something polished emerges here.

No worries!

In any case, if you're stuck or have questions just ping us 🙂

[nielsdos]

Looks much much better! Thanks!
I have some review comments, but the hard part of the work is over :)

[outtersg]

Thanks @nielsdos for your second, exhaustive review (and your responsiveness)!

Your advice made a monstrously satisfying simplification and clarification to the whole thing.

Three notes:

• for reviewing purpose, I like to keep individual commits, but here the history begins to look like Amazonia: do I need to squash? (or will it be done at merging, so that the branch can keep its prolific history?)
• I let two comments unresolved, waiting for your verdict. I had to give my somewhat controversial point of view, but really I'm torn between both ways
• I chose not to store the FCC as is in the pdo_pgsql_db_handle, but instead rely on a pointer: as pgsqlSetNoticeCallback is uncommon, having a full unitialized FCC there 99,999 % of the time would have been a waste of bytes (yes, I'm counting them one by one!)

[nielsdos]

Thanks @nielsdos for your second, exhaustive review (and your responsiveness)!

Your advice made a monstrously satisfying simplification and clarification to the whole thing.

You're welcome!

Three notes:

* for reviewing purpose, I like to keep individual commits, but here the history begins to look like Amazonia: do I need to squash? (or will it be done at merging, so that the branch can keep its prolific history?)

No need to worry about the history. We will do the squash upon merging.

* I let two comments unresolved, waiting for your verdict. I had to give my somewhat controversial point of view, but really I'm torn between both ways

Replied on your comment 🙂

* I chose _not_ to store the FCC as is in the pdo_pgsql_db_handle, but instead rely on a pointer: as pgsqlSetNoticeCallback is uncommon, having a full unitialized FCC there 99,999 % of the time would have been a waste of bytes (yes, I'm counting them one by one!)

That's fine, it makes sense.

[nielsdos]

Thank you for your work! Looks good to me.
@devnexen Want to have a final sanity check and take it from here?

[devnexen]

Thanks I ll have a last look tomorrow :)

[devnexen]

Thanks for your work !

[kocsismate]

@outtersg Was the new method intentionally not added to the new PdoPgsql class?

[outtersg]

@kocsismate wrote:

@outtersg Was the new method intentionally not added to the new PdoPgsql class?

:-\ I started this closely following pgsqlCopyFromArray (available but undocumented), and I didn't think to check if anything had changed regarding the exposition points of all those semi-public functions.

… But nothing is unchangeable, see #14299.