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 по дате отправления: