From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jens-Wolfhard Schicke-Uffmann <drahflow(at)gmx(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Parameter binding for COPY TO queries |
Date: | 2025-02-14 19:50:33 |
Message-ID: | s45xxcatvkl3blte4jcaorrke6saddqamfuls4impcvhc3jnz7@kdewpeudwkik |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2025-02-14 10:06:13 -0500, Tom Lane wrote:
> None of those arguments apply to the sub-SELECT of a "COPY (query) TO"
> command, but there's a practical matter of how to get the parameters
> passed through the COPY to the sub-SELECT without opening Pandora's
> box for every other kind of utility statement.
I think there's already precedent - CREATE TABLE AS does accept parameters
today, and it's a utility command too:
DROP TABLE IF EXISTS foo;
CREATE TABLE foo AS SELECT $1 as a, $2 as b \bind fooval, barval \g \d foo
Is there anything stopping us from implementing COPY along the same lines as
CTAS? There's some special case code for it, but it seems within reason,
unless we want to make dozens of commands accepting parameters...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2025-02-14 20:51:37 | Re: New buildfarm animals with FIPS mode enabled |
Previous Message | R, Rakshit | 2025-02-14 19:15:45 | RE: SIMD optimization for list_sort |