Re: Proposal: variant of regclass
| От | Tatsuo Ishii | 
|---|---|
| Тема | Re: Proposal: variant of regclass | 
| Дата | |
| Msg-id | 20131206.084412.595770378782775740.t-ishii@sraoss.co.jp обсуждение исходный текст  | 
		
| Ответ на | Re: Proposal: variant of regclass (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | 
                	
            		Re: Proposal: variant of regclass
            		
            		 | 
		
| Список | 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 по дате отправления: