Peter Eisentraut wrote:
> I don't get it. Say I execute SELECT a, b, c FROM foo;. In order to
> update that query, the application needs to create some update statement,
> say UPDATE foo SET a = entered_value;. 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';
Once the statement uses aliases for the result columns this can go
wrong. And to determine the correct table is difficult at best.
> With this proposed change, it can replace that with
>
> SELECT whatever FROM pg_attribute, pg_class WHERE oid = X AND attnum = Y;
>
> With the difference that the first version always works and the second
> version sometimes works, and when that sometimes is is determined by the
> rule that it should be "obvious". That doesn't seem right to me.
I have the impression that the first solution sometimes works (and other
times gets it really wrong, you can't tell without parsing the query)
and the second solution works when possible (and gives no answer
elsewhere). The only cases I expect the second one to fail are: natural
joins (where the table is ambigious), expressions and function calls. Of
course you can't expect a sane result in these cases.
On a second thought I do not want the column name (or alias) to get
discarded (because otherwise you can't get the alias), but *DBC
desperately needs attrelid and attnum.
Christof