From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Mark Feit <mfeit+postgresql(at)notonthe(dot)net> |
Subject: | Re: [PATCHES] Current-stream read for psql's \copy |
Date: | 2004-02-10 17:36:32 |
Message-ID: | 17339.1076434592@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I will do it by vote, not because _I_ decide it is unintuitive. And I
> don't have to talk _you_ into it, just a majority of developers.
[shrug...] Put it to a vote if you want; I feel sure you will lose.
There is another argument in favor of being able to read COPY data from
stdin (ie, not from the command script), which is that it is a security
feature that can help prevent SQL-injection attacks. In the example of
data-source-program | psql -f script
the upstream program *cannot* insert any SQL commands, it can only
source data that will go into exactly the table the script specifies.
The workaround you proposed of having the upstream issue COPY for itself
is insecure; it's quite analogous to allowing a user to enter unquoted
data into a SQL command string.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2004-02-10 17:39:49 | Re: MS SQL features for new version |
Previous Message | Bruce Momjian | 2004-02-10 17:33:10 | Re: [PATCHES] Current-stream read for psql's \copy |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-10 17:42:01 | Re: [GENERAL] dblink - custom datatypes don't work |
Previous Message | Bruce Momjian | 2004-02-10 17:33:10 | Re: [PATCHES] Current-stream read for psql's \copy |