From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: COPY IN as SELECT target |
Date: | 2009-12-17 18:26:35 |
Message-ID: | 4B2A77DB.2000305@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>
>> Andrew Dunstan wrote:
>>
>>> COPY RETURNING ARRAY FROM ...
>>>
>
>
>> It's not really returning an array, is it? It's returning a bag of rows
>> like a (sub)query.
>>
>
>
>> How about just COPY FROM?
>>
>
> The problem with COPY FROM is that it hard-wires a decision that there
> is one and only one possible result format, which I think we pretty
> much proved already is the wrong thing. I'm not thrilled with "RETURNING
> ARRAY" either, but we need to leave ourselves wiggle room to have more
> than one result format from the same source file.
>
>
>
Well, we could have "RETURNING type-expression" with "text[]" supported
for the first iteration.
In answer to Heiki's argument, what I wanted was exactly to return an
array of text for each row. Whatever we have needs to be able to handle
to possibility of ragged input (see previous discussion) so we can't tie
it down too tightly.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-17 18:37:59 | Re: COPY IN as SELECT target |
Previous Message | Kevin Grittner | 2009-12-17 18:20:50 | Re: determine snapshot after obtaining locks for first statement |