From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Browne <cbbrowne(at)gmail(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Schema version management |
Date: | 2012-07-05 22:55:30 |
Message-ID: | 2644.1341528930@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christopher Browne <cbbrowne(at)gmail(dot)com> writes:
> On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-07-05 23:11:59 | Re: Patch: add conversion from pg_wchar to multibyte |
Previous Message | Alvaro Herrera | 2012-07-05 22:44:11 | Re: foreign key locks |