Tom Lane wrote:
Dimitri Fontaine <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
