> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 18 March 2003 06:26
> To: Peter Eisentraut
> Cc: Dave Page; PostgreSQL Development
> Subject: Re: [HACKERS] Roadmap for FE/BE protocol redesign
>
>
> Peter Eisentraut <peter_e@gmx.net> writes:
> > ... So the application already knows
> > that "foo" is the table and "a" is the column. So if the
> application
> > wants to know about details on the column "a", it can
> execute SELECT
> > whatever FROM pg_attribute, pg_class WHERE relname = 'foo'
> AND attname
> > = 'a'; With this proposed change, it can replace that with SELECT
> > whatever FROM pg_attribute, pg_class WHERE oid = X AND attnum = Y;
>
> Dave will correct me if I'm wrong --- but I think the issue
> here is that the client-side library (think ODBC or JDBC)
> needs to gain this level of understanding of a query that is
> presented to it as an SQL-source string. So no, it doesn't
> already know that "foo" is the table and "a" is the column.
> To find that out, it has to duplicate a lot of backend code.
That's basically it. pgAdmin jumps through hoops trying to parse the SQL
the user enters to figure out tables and columns etc, and currently the
ODBC driver doesn't even bother in many cases (it does have a 'Parse
Statements' option but that rarely helps) and ends up returning
incorrect info. I don't know much about the JDBC driver, but Barry did
say this fix would save him exactly the same problems.
Regards, Dave.