From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | robertmhaas(at)gmail(dot)com, pavel(at)gf(dot)microolap(dot)com, pavel(at)microolap(dot)com, andres(at)2ndquadrant(dot)com, ishii(at)sraoss(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: variant of regclass |
Date: | 2013-12-05 23:44:12 |
Message-ID: | 20131206.084412.595770378782775740.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2013-12-05 23:50:58 | Re: ANALYZE sampling is too good |
Previous Message | Omar Kilani | 2013-12-05 23:21:20 | Re: How to detect invisible rows caused by the relfrozenxid bug? |