Re: Add CREATE support to event triggers
От | Robert Haas |
---|---|
Тема | Re: Add CREATE support to event triggers |
Дата | |
Msg-id | CA+TgmoaNMJUew11meorQ6e9vcdHkNAV3gSd8GUdb=CTtQyjkLw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add CREATE support to event triggers (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: