Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Dec 5, 2013 at 9:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
I'm getting less enamored of just-change-the-input-behavior myself.
The case that occurred to me is, suppose somebody's got a table containing
a regclass or regproc column, and he dumps and reloads it. If the input
converter silently replaces unknown names by 0, he's at risk of unexpected
data loss, if the reload is done before he's created all the referenced
objects.
> 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.
Yeah, I was thinking of that too.
regards, tom lane