Re: Schema version management - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Schema version management
Date
Msg-id 17684.1341787945@sss.pgh.pa.us
Whole thread Raw
In response to Re: Schema version management  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Schema version management
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On lör, 2012-07-07 at 17:18 -0400, Tom Lane wrote:
>> Sure.  You need not look further than "/" to find an operator name that
>> absolutely *will* cause trouble if it's dumped into a filename
>> literally.

> But that problem applies to all object names.

In principle, yes, but in practice it's far more likely that operators
will have names requiring some sort of encoding than that objects with
SQL-identifier names will.

>> If we think that operators outside of extensions will be an infrequent
>> special case, what about just dumping all of them into a single file
>> named "operators"?  And similarly for casts?

> If we think they are an infrequent case, why make a fuss about it?  Just
> treat them like any other object.

> In practical terms, I dislike the particular solution proposed here.
> For one thing, it would undermine the original purpose of this whole
> thread, namely insulating dump output files from ordering differences.

That's a good point.  However, I think that there are no cases where
we'd have dependencies between operators (or between casts), so that
as long as the initial sort is well-defined for them, it shouldn't
really be an issue in practice.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: regex_fixed_prefix() is still a few bricks shy of a load
Next
From: Tatsuo Ishii
Date:
Subject: Re: Patch: add conversion from pg_wchar to multibyte