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
