Re: Proposal: variant of regclass

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Golub <pavel(at)gf(dot)microolap(dot)com>, Pavel Golub <pavel(at)microolap(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: variant of regclass
Date: 2013-12-05 15:52:50
Message-ID: 16347.1386258770@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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.

BTW, another arguable advantage of fixing this via new functions is
that users could write equivalent (though no doubt slower) functions
for use in pre-9.4 releases, and thus not need to maintain multiple
versions of app code that relies on this behavior.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Metin Doslu 2013-12-05 15:57:44 Re: Parallel Select query performance and shared buffers
Previous Message Peter Eisentraut 2013-12-05 15:52:47 Re: Proof of concept: standalone backend with full FE/BE protocol