Re: Add CREATE support to event triggers

On Thu, Feb 6, 2014 at 12:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>>>> Then again, why is the behavior of schema-qualifying absolutely
>>>> everything even desirable?
>
>>> Well, someone could create a collation in another schema with the same
>>> name as a system collation and the command would become ambiguous.
>
>> Hmm, good point. I guess we don't worry much about this with pg_dump
>> because we assume that we're restoring into an empty database (and if
>> not, the user gets to keep both pieces). You're applying a higher
>> standard here.
>
> Robert, that's just horsepucky. pg_dump is very careful about schemas.
> It's also careful to not schema-qualify names unnecessarily, which is an
> intentional tradeoff to improve readability of the dump --- at the cost
> that the dump might break if restored into a nonempty database with
> conflicting objects. In the case of data passed to event triggers,
> there's a different tradeoff to be made: people will probably value
> consistency over readability, so always-qualify is probably the right
> choice here. But in neither case are we being sloppy.

I didn't mean to imply otherwise. I know the pg_dump tries to avoid
excess schema-qualification for readability among other reasons; what
I meant was that Alvaro is applying a higher standard specifically in
regards to replayability.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company