Re: Schema version management

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Schema version management
Дата
Msg-id 1341501164-sup-2200@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: Schema version management  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Schema version management  (Joel Jacobson <joel@trustly.com>)
Re: Schema version management  (Michael Glaesemann <grzm@seespotcode.net>)
Re: Schema version management  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
Excerpts from Tom Lane's message of jue jul 05 10:46:52 -0400 2012:
> Joel Jacobson <joel@trustly.com> writes:
> > Maybe it could be made an option to pg_dump?
>
> Ick.  Then we have to deal with all the downsides of *both* methods.
>
> pg_dump is already a bloated, nearly unmaintainable mess.  The very
> last thing it needs is even more options.

Agreed.

However I am also against what seems to be the flow.  Normally, you
don't write overloaded plpgsql functions such as "equal".  Case in
point, the equality functions in core have funny names like "int4eq" and
so on.  Instead, at least in my experience, the overloaded functions
people seem to have in their databases are like do_stuff_to_foobars()
and you have one version for foos and another one for bars.

If you're doing lots of equality functions, surely it would make more
sense to package them up as an extension anyway along with all the other
thingies you need for the type you're supposedly writing.  So it's a
completely different market than what we're aiming at here.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joel Jacobson
Дата:
Сообщение: Re: Schema version management
Следующее
От: Joel Jacobson
Дата:
Сообщение: Re: Schema version management