Re: Inconsistent behavior with unnamed columns

Moshe Jacobson wrote
> Why does bool get special treatment?
>
> postgres# select 'abc', 1, false;
> ?column? | ?column? | bool
> ----------+----------+------
> abc | 1 | f
> (1 row)

It doesn't (at least not as I see things in my client/version - noted
below):

*SELECT 'abc'::text;*

If the type is known the type is used for the column header but since 'abc'
and 1 do not have types this does not work. I guess the default type that
these get casted to could be used (text, int4) - though I doubt that would
be a simple or worthwhile change.

*SELECT 'abc'::text, 'def'::text, 'ghi'::varchar, 1::int*

If a type is repeated a '_#' is added to the resultant output column name (#
incrementing from 1)

*SELECT 'abc'::text, 'def'::text, 'ghi'::varchar, 1::int, 'u1', 'u2', 1*

(text, text_1, varchar, int4, ?column?, ?column?_1, ?column?_2

The same apparently happens for "?column?" as in "?column?_1" though you do
not show it doing so in your example. This may be client specific behavior
though I doubt it.

My observations are using:

version
PostgreSQL 9.0.3 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real
(Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64-bit

Via the PostgreSQL Maestro client

(test machine I haven't gotten around to upgrading)

This kind of behavior is apt to be tweaked between versions as relying on
generated column names is not accommodated for (I don't think so anyway).

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Inconsistent-behavior-with-unnamed-columns-tp5772890p5772894.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.