> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
