pg_conversion seems rather strangely defined

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pg_conversion seems rather strangely defined
Дата
Msg-id 6198.1452019611@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: pg_conversion seems rather strangely defined  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pg_conversion seems rather strangely defined  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
What is the point of pg_conversion.condefault (the flag that says whether
a conversion is "default")?  AFAICS, there is absolutely no way to invoke
a conversion that is not default, which means we might as well eliminate
the concept.

I do not see a lot of point in the namespacing of encoding conversions
either.  Does anyone really need or use search-path-dependent lookup of
conversions?  (If they do, it's probably broken anyway, since for example
we do not trouble to re-identify the client encoding conversion functions
when search_path changes.)

While actually removing pg_conversion.connamespace might not be worth
the trouble, it's mighty tempting to have just a single unique index on
(conforencoding, contoencoding), thereby enforcing that There Can Be Only
One conversion between any given pair of encodings, and then we can just
use that index to find the right entry without any fooling with search
path.

But in any case we should get rid of the concept of defaultness, because
it's pointless; all entries should be equally "default".
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Beginner hacker item: Fix to_reg*() input type
Следующее
От: Petr Korobeinikov
Дата:
Сообщение: Re: Beginner hacker item: Fix to_reg*() input type