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

From Tatsuo Ishii
Subject Re: Proposal: variant of regclass
Date
Msg-id 20131206.084412.595770378782775740.t-ishii@sraoss.co.jp
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
> 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.

Can I make sure that we want to keep the current behavior:

test=# SELECT 'pg_klass'::regclass;
ERROR:  relation "pg_klass" does not exist
LINE 1: SELECT 'pg_klass'::regclass;              ^

Or do we want the SELECT to return 0 in the case above?
I'm asking because of this:
>> So 'pg_klass'::regclass could return 0,
>> but not NULL.

In the mean time I agree the idea that we add:toregclass(text) returns regclass
and friends.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Omar Kilani
Date:
Subject: Re: How to detect invisible rows caused by the relfrozenxid bug?
Next
From: Josh Berkus
Date:
Subject: Re: ANALYZE sampling is too good