Re: Proposal: variant of regclass

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Proposal: variant of regclass
Дата
Msg-id CA+TgmoZ2fz57orck5=Q7rzJM=dRYkMJp8VHYqM8qNbykAgPhdQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: variant of regclass  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proposal: variant of regclass
Список pgsql-hackers
On Thu, Dec 5, 2013 at 9:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavel Golub <pavel@microolap.com> writes:
>> I personally see two approaches:
>> 1. Implement GUC variable controling this behaviour per session
>> 2. Introduce new safe reg* variables, e.g. "sregclass", "sregtype" etc.
>
> I don't think new types are a good idea.  If we are afraid to change
> the behavior of the input converters, what we should do is introduce
> new functions, eg "toregclass(text) returns regclass".

That seems like a pretty reasonable approach.

I don't have a strong opinion on whether it's worth the
backward-compatibility break that would ensue from just changing this
outright.  I admit that I've been annoyed by this behavior more than
once, but I've also been beaten by customers enough times to know that
backward-compatibility has value to other people in some cases where
it does not have such value to me.

Another advantage of this approach is that, IIUC, type input functions
can't return a NULL value.  So 'pg_klass'::regclass could return 0,
but not NULL.  On the other hand, toregclass('pg_klass') *could*
return NULL, which seems conceptually cleaner.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: "MauMau"
Дата:
Сообщение: [RFC] Shouldn't we remove annoying FATAL messages from server log?
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: shared memory message queues