Re: SELECT my_table.varchar FROM my_table

From: Jan Strube <js(at)deriva(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Richard Broersma <richard(dot)broersma(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: SELECT my_table.varchar FROM my_table
Date: 2010-05-31 15:59:15
Message-ID: 4C03DCD3.5050104@deriva.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Am 31.05.2010 17:44, schrieb Tom Lane:
> Richard Broersma<richard(dot)broersma(at)gmail(dot)com> writes:
>
>> On Mon, May 31, 2010 at 7:48 AM, Jan Strube<js(at)deriva(dot)de> wrote:
>>
>>> I accidentally encountered a feature in Postgres 8.3 that I couldn't find in
>>> the documentation while submitting a query like
>>>
>>> SELECT my_table.varchar FROM my_table
>>>
>>> which returns a concatenated string of all field values per row.
>>> I wonder where this is documented (and if it has something to do with
>>> composite types).
>>>
>>> Can anyone please explain?
>>>
>
>> I don't really know, but the result looks more like a single field
>>
> It's equivalent to (my_table.*)::varchar. We've seen enough people
> confused by this (or the equivalent cases with text and name as
> the target type) that I wonder if we should intentionally break the
> symmetry and disable treating this case as a cast. Although I do
> rather wonder what the OP expected to happen here.
>

I didn't expect anything special, because my original statement was
actually a typo. So I was just amazed that I didn't get an error.

Thanks for the explanation,
Jan

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Wappler, Robert 2010-05-31 16:00:00 Nested function invocation, but parameter does not exist
Previous Message Tom Lane 2010-05-31 15:44:42 Re: SELECT my_table.varchar FROM my_table