> -----Original Message----- > From: pgsql-sql-ow...@postgresql.org [mailto:pgsql-sql- > ow...@postgresql.org] On Behalf Of John Fabiani > Sent: Thursday, June 07, 2012 7:18 PM > To: pgsql-sql@postgresql.org > Subject: [SQL] using ordinal_position > > I'm attempting to retrieve data using a select statement without knowing the > column names. I know the ordinal position but not the name of the column > (happens to be a date::text and I have 13 fields). > > Below provides the name of the column in position 3: > > select column_name from (select column_name::text, ordinal_position from > information_schema.columns where > table_name='wk_test') as foo where ordinal_position = 3; > > But how can I use the above as a column name in a normal select statement. > > Unlike other databases I just can't use ordinal position in the select > statement - RIGHT??? > > Johnf >
This seems like a seriously messed up requirement but I guess the easiest way would be as follows: SELECT tbl.col3 FROM (SELECT * FROM table) tbl (col1, col2, col3) Basically you select ALL columns (thus not caring about their names and always getting the defined order) from the table and give explicit aliases to columns 1 though N where N is the desired column position you want to return. All subsequent columns will retain their original names. If the parent query you can then simply select the column alias you assigned to the desired column position. If you query the catalog for the true column name you would have to use pl/pgSQL and EXECUTE to run the query against a manually built (stringified) query; SQL proper does not allow for table and column names to be variable. That said you may find it worthwhile to publish the WHY behind your inquiry to see if some other less cumbersome and error-prone solution can be found. While column order is fairly static it is not absolute and if the column order were to change you would have no way of knowing. At least when using actual column names the query would fail with an unknown column name exception instead of possibly silently returning bad data. The extra layer of indirection just seems dirty to me - but aside from the possibility of column order changes I don't see any major downsides. Since you are just dealing with column aliases it should not meaningfully impact query plan generation and thus it should be no slower than a more direct query. David J. -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql