Re: Proposal: variant of regclass - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposal: variant of regclass
Date
Msg-id CA+TgmoZ2fz57orck5=Q7rzJM=dRYkMJp8VHYqM8qNbykAgPhdQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: variant of regclass  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: variant of regclass
List 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 by date:

Previous
From: "MauMau"
Date:
Subject: [RFC] Shouldn't we remove annoying FATAL messages from server log?
Next
From: Kohei KaiGai
Date:
Subject: Re: shared memory message queues