Обсуждение: Inconsistent behavior with unnamed columns

On 09/30/2013 01:48 PM, Moshe Jacobson wrote:
> Why does bool get special treatment?
>
> |postgres# select 'abc', 1, false;
>   ?column? | ?column? | bool
> ----------+----------+------
>   abc      |        1 | f
> (1 row)|


Not always:

test=> select 'abc'::text, 1::int, 'f';
  text | int4 | ?column?
------+------+----------
  abc  |    1 | f





>
> Moshe Jacobson
> Nead Werx, Inc. | Manager of Systems Engineering
> 2323 Cumberland Parkway, Suite 201 | Atlanta, GA 30339
> moshe@neadwerx.com <mailto:moshe@neadwerx.com> | www.neadwerx.com
> <http://www.neadwerx.com/>
>
> “Quality is not an act, it is a habit.” — Aristotle
>


--
Adrian Klaver
adrian.klaver@gmail.com

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.

David Johnston <polobo@yahoo.com> writes:
> 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.

A look into gram.y shows that "false" is parsed as 'f'::bool, so the
default column header name comes from that cast.  See also FigureColname()
in parser/parse_target.c, which embodies the heuristics for choosing a
default column name for an expression.

            regards, tom lane