Re: Schema version management - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Schema version management
Date
Msg-id 1341501164-sup-2200@alvh.no-ip.org
Whole thread Raw
In response to Re: Schema version management  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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>)
List 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 by date:

Previous
From: Joel Jacobson
Date:
Subject: Re: Schema version management
Next
From: Joel Jacobson
Date:
Subject: Re: Schema version management