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
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 |