From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Joel Burton" <joel(at)joelburton(dot)com> |
Cc: | "Pgsql-Hackers(at)Postgresql(dot) Org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Exposed function to find table in schema search list? |
Date: | 2002-05-24 17:33:14 |
Message-ID: | 12824.1022261594@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Joel Burton" <joel(at)joelburton(dot)com> writes:
> Well, sort of, but if we had been promoting a function tableoid(text)
> returns oid, we wouldn't have to make any change for the move to regclass,
> would we? I mean, it's specific to PG, but a simple wrapper might outlive
> the next under-the-hood change.
I think you miss the point: regclass is that wrapper. tableoid(text)
is only syntactically different --- and for that matter there's nothing
stopping you from writing regclass('tablename').
> On a related note: is there an easy way to use this ::regclass conversion to
> test if a table exists in a non-error returning way? (Can I use it in a
> select statement, for instance, returning a true or false value for the
> existence or non-existence of a table?)
At the moment regclass conversion raises an error if the item isn't
found; this follows the historical behavior of regproc. We could
possibly have it return 0 (InvalidOid) instead, but I'm not convinced
that that's better. In the case of regproc, not erroring out would
lose some important error checking during initdb.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gunther Schadow | 2002-05-24 17:43:36 | Alternatives to SQL ... |
Previous Message | Joe Conway | 2002-05-24 17:27:18 | Re: Redhat 7.3 time manipulation bug |