Ken Johanson <pg-user@kensystem.com> writes: > While the values of an API that specifies the table's columns by > ordinaility may seem dubious, it is an API that I think should be > implemented anyway. Every few weeks we get a complaint from someone who thinks that it should be easy to rearrange the logical order of table columns. If that comes to pass, it would be a seriously bad idea to have encouraged applications to rely on table column numbers. And given the number of votes for that (probably in the hundreds by now) versus the number of votes for this idea (one), I think column reordering is much more likely to get done ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Kris Jurka <books@ejurka.com> writes: > I think the expectation is that: > CREATE TABLE t(a int, b int); > INSERT INTO t(b,a) VALUES (1,2) RETURNING *; > will return 1,2 instead of 2,1 as it does now. Hmm ... I see your point, but on what grounds could one argue that a "*" targetlist here should return something different from what "SELECT * FROM t" would return? I'd say that an app that wants that should write INSERT INTO t(b,a) VALUES (1,2) RETURNING b,a; which is surely not that hard if you've got the code to produce the "(b,a)" part. In any case it's not clear this is the same thing Ken is complaining about ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org/