PdoPgsql::setNoticeCallback()

[outtersg]

Make the newly implemented setNoticeCallback() officially exposed in @kocsismate / @Danack Pdo\Pgsql (discussion begun at #6764)

[outtersg]

@nielsdos you may be interested in reviewing this complement (hoping I did not break the beautiful work we did on #6764…).

[nielsdos]

Sorry, I didn't think of those new classes.
I have a suggestion on how to simplify this.
Also: the CI currently fails because the stub isn't regenerated into the arginfo file. That usually happens automatically when you do make. You can force it manually by doing: ./build/gen_stub.php.

[outtersg]

@nielsdos wrote:

Also: the CI currently fails because the stub isn't regenerated into the arginfo file.
That usually happens automatically when you do make. You can force it manually by doing: ./build/gen_stub.php.

Yes, it's not the first time I got caught by the CI :(
But git diff seeing the arginfo as binary made me visually miss it when adding to the commit.

[devnexen]

@outtersg here when you can.

[kocsismate]

Thanks for the quick followup! Please update the UPGRADING note + maybe a dedicated test for PdoPgsql:: setNoticeCallback() would be useful to have. And then I guess it is good to go.

[outtersg]

@kocsismate wrote:

Thanks for the quick followup! Please update the UPGRADING note

Something like "Added PdoPgsql::setNoticeCallback() / PDO::pgsqlSetNoticeCallback to allow […]"?

maybe a dedicated test for PdoPgsql:: setNoticeCallback() would be useful to have. And then I guess it is good to go.

Here it is, with 6dee3db.

[kocsismate]

Something like "Added PdoPgsql::setNoticeCallback() / PDO::pgsqlSetNoticeCallback to allow […]"?

Exactly :)

[outtersg]

We're good to go after retriggering Travis CI (which has a timeout of 50 mn on a 45 mn+ job…)!

Still, there's the egg-and-chicken question of how to make PdoPgsql::Xxx the official entry point, while letting PDO::pgsqlXxx available until connect becomes mainstream (and I think third parties already switched to not subclassing PDO anymore, but proxying it).
@Girgias, @kocsismate, @Danack, do you think of a way to solve this elegantly?

[Danack]

do you think of a way to solve this elegantly?

I would only add support for PdoPgsql::Xxx and then only think about adding a PDO::pgsqlXxx version if someone offered to pay me something like £10k

Hardcoding the class seems to defeat the universal purpose of PDO (switching from SQLite to pg with a single DSN change)

You're testing a DB specific method. It's fine to hard code the class name.

(it is possible you might get a more useful answer from someone not quite as in a mood as myself)

[Girgias]

Missing tests, and I still believe we should not be adding new "magic" driver methods to the core PDO class.

[outtersg]

@Danack wrote:

(it is possible you might get a more useful answer from someone not quite as in a mood as myself)
[…]
You're testing a DB specific method. It's fine to hard code the class name.

See my reply in the conversation.

[kocsismate]

Thank you for your work, I believe this is now much better than the original solution was with the 2 methods. :) I mean, I agree with Dan and George, let's not add anything to the old and clunky API. Unfortunately, I didn't realize the importance of this when I first reviewed the PR.

[kocsismate]

I noticed it still had references to PdoXxx instead of Pdo\Xxx.

Sorry, my fault. I also forgot to update them yesterday :(

[nielsdos]

Unless I'm mistaken, you're still missing a test where you test that a trampoline does not leak on an uninitialized pdo instance?

[outtersg]

@nielsdos wrote:

Unless I'm mistaken, you're still missing a test where you test that a trampoline does not leak on an uninitialized pdo instance?

OK, I'm not familiar at all with how to test that.
By reading sqlite3_trampoline_*_no_leak.phpt, if I understand correctly:

• I should test multiple invalid combinations, one by one, on the same object
• Each callback should gracefully return a "must be a valid callback", but should not output leaks
• Then I could too test on a newInstanceWithoutConstructor(), same thing
• And then a final, correct, call, with a trampoline instead of a direct function.

Is that right?

But I see no "Trampoline for" in the output: are we just testing the set of the callback, not its execution at runtime?

[nielsdos]

What you've done so far is right, but you should also test the set method on an uninitialized PDO instance.
You can create a PDO instance and test with it like so: https://github.com/php/php-src/blob/a580d4a1c319203053ab66cdf1205f126d96e667/ext/pdo/tests/pdo_uninitialized.phpt
In the case of PdoPgsql, you can create a new instance using new PdoPgsql and this will be uninitialized. Then you can test whether the set method on such an uninitialized instance correctly errors out and does not leak when given a trampoline.

[outtersg]

@nielsdos wrote:

[…] test with it like so: …/ext/pdo/tests/pdo_uninitialized.phpt

I almost had it 😞, in a commented, uncommited part of my local pdopgsql_setNoticeCallback.phpt,
and with a newInstanceWithoutConstructor() as seen in sqlite3_trampoline_*_no_leak.phpt.

In the case of PdoPgsql, you can create a new instance using new PdoPgsql and this will be uninitialized.

On a theorical point of view, is there a difference between newInstanceWithoutConstructor() and subclassing with a constructor short-circuit? (a direct new Pdo\Pgsql() throws, requiring at least 1 arg)
For example, do class members initialized at declaration (protected $thing = 'bla') get initialized with an empty constructor, but not with newInstanceWithoutConstructor(), or is it strictly equivalent?
(in the case of an internal class like Pdo\Pgsql I doubt there are class members of course)

[nielsdos]

Thanks for the test!

In the case of PdoPgsql, you can create a new instance using new PdoPgsql and this will be uninitialized.

On a theorical point of view, is there a difference between newInstanceWithoutConstructor() and subclassing with a constructor short-circuit? (a direct new Pdo\Pgsql() throws, requiring at least 1 arg) For example, do class members initialized at declaration (protected $thing = 'bla') get initialized with an empty constructor, but not with newInstanceWithoutConstructor(), or is it strictly equivalent? (in the case of an internal class like Pdo\Pgsql I doubt there are class members of course)

It is equivalent, the properties are initialized when the object is allocated before calling the constructor. In case no constructor is called the properties are initialized.

I think the patch looks good.

@Girgias I believe all cases are now covered.

[Girgias]

Thank you! Looks good to me now :)

[Girgias]

This might make sense to add to other drivers in a follow-up PR.