Re: COPY Transform support

Tom Lane wrote:
> Dimitri Fontaine <dfontaine@hi-media.com> writes:
>   
>> Le mardi 08 avril 2008, Tom Lane a écrit :
>>     
>>> That's sufficiently covered by the proposal to allow a COPY FROM as a
>>> table source within SELECT, no?
>>>       
>
>   
>> Well, yes, the table source has text as datatypes and the select expression on 
>> the column will call whatever function/cast etc to do the work. But that 
>> opens the door to second class citizen storage solution for PostgreSQL, by 
>> letting the user CREATE VIEW atop of it:
>>     
>
> [ shrug... ]  I don't actually have a problem with that.  If we did want
> to prohibit that, we'd have to somehow prohibit SRFs from reading files,
> because you can do it today with any untrusted PL.
>
> I note also that presumably COPY FROM 'file' would still be restricted
> to superusers, and only COPY FROM STDIN would be available to those
> without a license to shoot themselves in the foot.  So the opportunity
> to do anything view-like would be restricted to adults(?) anyhow.
>   


Yeah, maybe. I will suspend my doubts for now.

> (One of the issues that'd have to be addressed to allow a table source
> syntax is whether it's sane to allow multiple COPY FROM STDIN in a
> single query.  If so, how does it work; if not, how do we prevent it?)
>
>             
>   

I don't see why it shouldn't work. I see that copy.c now looks like it's 
reentrant, unlike the bad days of old. Could we make each COPY target 
behave like an SRF, stashing its data in a tuplestore?

cheers

andrew