Re: Schema version management

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Schema version management
Дата
Msg-id 17684.1341787945@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Schema version management  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Schema version management  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: regex_fixed_prefix() is still a few bricks shy of a load
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Patch: add conversion from pg_wchar to multibyte