Re: Schema version management

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

In response to

Responses

Browse pgsql-hackers by date

  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