Re: Schema version management

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Schema version management
Дата
Msg-id
17684.1341787945@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Daniel Farina <daniel@heroku.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Daniel Farina <daniel@heroku.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Daniel Farina <daniel@heroku.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Andrew Dunstan <andrew@dunslane.net>
Re: Schema version management Daniel Farina <daniel@heroku.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Tom Lane <tgl@sss.pgh.pa.us>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Robert Haas <robertmhaas@gmail.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Peter Eisentraut <peter_e@gmx.net>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Robert Haas <robertmhaas@gmail.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Gurjeet Singh <singh.gurjeet@gmail.com>
Re: Schema version management Andrew Dunstan <andrew@dunslane.net>
Re: Schema version management "David E. Wheeler" <david@justatheory.com>
Re: Schema version management Aidan Van Dyk <aidan@highrise.ca>
Re: Schema version management Josh Berkus <josh@agliodbs.com>
Re: Schema version management Michael Glaesemann <grzm@seespotcode.net>
Re: Schema version management Vik Reykja <vikreykja@gmail.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Tom Lane <tgl@sss.pgh.pa.us>
Re: Schema version management Alvaro Herrera <alvherre@commandprompt.com>
Re: Schema version management Michael Glaesemann <grzm@seespotcode.net>
Re: Schema version management Alvaro Herrera <alvherre@commandprompt.com>
Re: Schema version management Tom Lane <tgl@sss.pgh.pa.us>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Christopher Browne <cbbrowne@gmail.com>
Re: Schema version management Alvaro Herrera <alvherre@commandprompt.com>
Re: Schema version management Michael Glaesemann <grzm@seespotcode.net>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Re: Schema version management Peter Eisentraut <peter_e@gmx.net>
Re: Schema version management Aidan Van Dyk <aidan@highrise.ca>
Re: Schema version management Alvaro Herrera <alvherre@commandprompt.com>
Re: Schema version management Tom Lane <tgl@sss.pgh.pa.us>
Re: Schema version management Peter Eisentraut <peter_e@gmx.net>
Re: Schema version management Tom Lane <tgl@sss.pgh.pa.us>
Re: Schema version management Peter Eisentraut <peter_e@gmx.net>
Re: Schema version management Andrew Dunstan <andrew@dunslane.net>
Re: Schema version management Peter Eisentraut <peter_e@gmx.net>
Re: Schema version management Alvaro Herrera <alvherre@commandprompt.com>
Re: Schema version management Peter Eisentraut <peter_e@gmx.net>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Tom Lane <tgl@sss.pgh.pa.us>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Tom Lane <tgl@sss.pgh.pa.us>
Re: Schema version management Andrew Dunstan <andrew@dunslane.net>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Peter Eisentraut <peter_e@gmx.net>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Peter Eisentraut <peter_e@gmx.net>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Magnus Hagander <magnus@hagander.net>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Peter Eisentraut <peter_e@gmx.net>
Re: Schema version management Christopher Browne <cbbrowne@gmail.com>
Re: Schema version management Tom Lane <tgl@sss.pgh.pa.us>
Re: Schema version management Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Re: Schema version management Robert Haas <robertmhaas@gmail.com>
Re: Schema version management "Marc Mamin" <M.Mamin@intershop.de>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Tom Lane <tgl@sss.pgh.pa.us>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Benedikt Grundmann <bgrundmann@janestreet.com>
Re: Schema version management Merlin Moncure <mmoncure@gmail.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Re: Schema version management Merlin Moncure <mmoncure@gmail.com>
Re: Schema version management Joel Jacobson <joel@trustly.com>
Peter Eisentraut  writes:
> On lör, 2012-07-07 at 17:18 -0400, Tom Lane wrote:
>> Sure.  You need not look further than "/" to find an operator name that
>> absolutely *will* cause trouble if it's dumped into a filename
>> literally.

> But that problem applies to all object names.

In principle, yes, but in practice it's far more likely that operators
will have names requiring some sort of encoding than that objects with
SQL-identifier names will.

>> If we think that operators outside of extensions will be an infrequent
>> special case, what about just dumping all of them into a single file
>> named "operators"?  And similarly for casts?

> If we think they are an infrequent case, why make a fuss about it?  Just
> treat them like any other object.

> In practical terms, I dislike the particular solution proposed here.
> For one thing, it would undermine the original purpose of this whole
> thread, namely insulating dump output files from ordering differences.

That's a good point.  However, I think that there are no cases where
we'd have dependencies between operators (or between casts), so that
as long as the initial sort is well-defined for them, it shouldn't
really be an issue in practice.
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата:
От: Tatsuo Ishii
Дата:
FAQ