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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
