Re: Patch for Statement.getGeneratedKeys()

On Wed, 16 Jan 2008, Ken Johanson wrote:

>> I've lost track of the context in which this needs to be done, but in
>> some cases a cast to or from regclass offers a painless way to
>> disambiguate table names.  Just a suggestion ...
>
> Tom, can you offer an example of this and how the overall goal might be 
> achieved? Kris, please jump in where I'm missing anything:

Regclass is actually exactly what you need.  This let's us skip all kinds 
of parsing, deducing, ...

SELECT 'database.schema.table'::regclass::oid;
SELECT 'schema.table'::regclass::oid;
SELECT 'table'::regclass::oid;
SELECT '"database".schema."table"'::regclass::oid;

will all return the same thing, the oid for the qualified table, or if 
unqualified, the first matching table on the search path.  The oid will be 
pg_class.oid which can then easily be used to lookup the columns in 
pg_attribute as people have explained on -general.

> #Questions:
>
> -would the regclass-cast technique (I have no experience with it) work 
> directly in the RETURNING or need to be in the [information_schema] query? 
> Can you point me to examples?

Needs to be in a separate query.

> -would it be feasible to modify RETURNING in new server versions to accept 
> indexes as args? That would obviate this whole discussion.
>

Not really, RETURNING is an arbitrary SELECT list, so you can say things 
like RETURNING 1, 2+columnA, f(columnB).  You could potentially add some 
kind of keyword like RETURNING INDEXES 1,2,7, but I doubt the server 
people have a great desire to support something this braindead for just 
one client API to use.

Kris Jurka