Robert Haas <robertmhaas@gmail.com> writes:
> If I thought there were some useful code, I would try to see if we
> could contribute it, but I'm pretty sure there isn't. We have a bunch
Oh. Too bad.
[... description of the tool ...]
> I don't see a way to do the exact kind of testing we need here in a
> cross-platform way using that infrastructure.
Well, do we have \! in psql in windows at all? does it work in a similar
way to the unix one? I just don't know.
> I'm tempted to propose that we define a Perl-based testing API for
> "additional regression tests" that can't be handled using pg_regress.
I know that our build requirements are pretty stable for very good
reasons and I appreciate that. Now, I don't do perl. I'll happily use
whatever you come up with, though.
>> command and our lookup, but I could easily get convinced to look up the
>> catalogs instead, even more so once we have the OID of the object easily
>> available in all places.
>
> I haven't looked at the code, but it seems to me that there have got
> to be edge cases where that will fail. For one thing, we only do
In between that email and the latest patch I've removed any processing
of the parse tree, because without the ddl_rewrite module it didn't make
much sense anyway, and I still want to be sure we have ObjectID, Name
and Schema as a base information set.
> Really, the only safe way to do these things is to have any given name
> lookup done in one and only one place. We're some distance from there
> and there and I don't know that this patch should be required to carry
> the burden of nailing down all the loose ends in that area, but I
> think it's reasonable to insist that it shouldn't do anything which
> makes it impossible for someone else to nail down those loose ends,
> which is still fairly high on my personal to-do list.
The current version of the patch now does its own lookup, and only does
so at a time when the object exists in the catalogs. So I think we're
now good on that front in the current Event Triggers patch, even if it's
not refactoring all and any DDL to be able to add hooks in between
lookups and locks, for example.
Also, several cases appear to need an extra lookup anyway, such as ALTER
OBJECT … RENAME TO … or ALTER OBJECT … SET SCHEMA … when you want to
feed information to a ddl_command_end Event Trigger…
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support