Tom Lane writes:
> Yes, Dave did answer --- basically, he's happy with not providing any
> column identity data in the cases where it's not obvious what the answer
> should be. And in particular he doesn't want the mechanism to drill
> down into view definitions (which is less than obviously right to me,
> but if that's what he wants it sure eliminates a lot of definitional
> issues).
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';
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.
--
Peter Eisentraut peter_e@gmx.net
