Re: Add CREATE support to event triggers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Add CREATE support to event triggers
Date
Msg-id CA+TgmoaNMJUew11meorQ6e9vcdHkNAV3gSd8GUdb=CTtQyjkLw@mail.gmail.com
Whole thread Raw
In response to Re: Add CREATE support to event triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Feb 6, 2014 at 12:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera <alvherre@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Performance Improvement by reducing WAL for Update Operation
Next
From: Craig Ringer
Date:
Subject: Re: Row-security on updatable s.b. views