Skip site navigation (1) Skip section navigation (2)

Re: Support for DatabaseMetadata: getCatalogName, getTableName,

From: Kris Jurka <books(at)ejurka(dot)com>
To: Ken Johanson <pg-user(at)kensystem(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Support for DatabaseMetadata: getCatalogName, getTableName,
Date: 2007-01-04 22:32:43
Message-ID: Pine.BSO.4.64.0701041724580.18682@leary2.csoft.net (view raw or flat)
Thread:
Lists: pgsql-jdbc

On Thu, 4 Jan 2007, Ken Johanson wrote:

>> Right now we don't have the information to return "d" and so we must 
>> always return the empty string. Getting the base column and table names 
>> seems more useful but does not appear to be what the javadoc and spec 
>> imply as the behavior of the standard API methods.
>> 
>
> So to be sure, this (literal and alias name differentiation) actually is not 
> being provided via the current server V3 protocol or server?

What we get now in the V3 protocol:

1) the column name which may be an alias but we don't know if it came from 
an alias or not, consider SELECT a AS a.  If we get "a" we don't know if 
it was aliased or not.

2) The underlying table's oid which can be used to lookup it's name and 
schema.

3) The underlying column's number in the table which can be used to lookup 
its name.

No information on a table alias is available.

> If so, does anyone know off hand if V3 is somehow extensible; i.e can we add 
> in metadata without breaking apps or major version?
>

No the RowDescription message is fixed:

http://www.postgresql.org/docs/current/static/protocol-message-formats.html

> Again, just trying to get an idea of how near or far off this may be. I think 
> there are several high level object persistence wrappers out there that 
> depend (right or wrong) on table names/aliases to reconstitute objects from 
> selects and natural/inner joins.
>

It's a ways off and even if it was working you have to think about things 
like self joins and calculated results.  What can a tool do with these?

SELECT t1.col, t2.col, 1+3 FROM tab t1, tab t2 WHERE t1.a = t2.b;

And app would need some serious smarts to unravel this sort of thing.

Kris Jurka

In response to

Responses

pgsql-jdbc by date

Next:From: Ken JohansonDate: 2007-01-04 22:54:14
Subject: Re: Support for DatabaseMetadata: getCatalogName, getTableName,
Previous:From: Ken JohansonDate: 2007-01-04 22:19:18
Subject: Re: Support for DatabaseMetadata: getCatalogName, getTableName,

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group