Re: Schema version management - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Schema version management
Date
Msg-id 2644.1341528930@sss.pgh.pa.us
Whole thread Raw
In response to Re: Schema version management  (Christopher Browne <cbbrowne@gmail.com>)
Responses Re: Schema version management
List pgsql-hackers
Christopher Browne <cbbrowne@gmail.com> writes:
> On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>> FWIW, I'm attracted to the all-similarly-named-functions-together
>>> method, mainly because it dodges the problem of how to encode a
>>> function's argument list into a filename.  However, we're being
>>> short-sighted to only think of functions here.  What about operators?
>>> Or casts?  Those don't have simple names either.

>> I would argue like �lvaro that when dealing with operators and casts
>> you're probably writing an extension already, and we're providing
>> another way to deal with that.

> Indeed.  Is this something we ought to document as a recommendation?

This argument seems a bit irrelevant to me.  pg_dump doesn't get to pick
and choose what will be in the database it's told to dump.  If we're
going to do something like what Joel wants, we have to have file naming
conventions for operator and cast objects.  So we can't just leave them
out of the conversation (or if we do, we shouldn't be surprised when the
ensuing design sucks).
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: foreign key locks
Next
From: Tom Lane
Date:
Subject: Re: Patch: add conversion from pg_wchar to multibyte