Re: COPY IN as SELECT target

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

In response to

Responses

Browse pgsql-hackers by date

  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