Re: COPY TO (query) allows no function arguments

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Färber, Franz-Josef (StMUK) <Franz-Josef(dot)Faerber(at)stmuk(dot)bayern(dot)de>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: COPY TO (query) allows no function arguments
Date: 2021-03-10 15:45:07
Message-ID: CAKFQuwa9KTE+sYuDzCbbh9Ae8aJRsmTpqs_bOK-6XnMfYmV7RA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Mar 10, 2021 at 8:17 AM Joe Conway <mail(at)joeconway(dot)com> wrote:

> EXECUTE $$COPY (SELECT * FROM $$ || myparam || $$) TO '/tmp/a.txt'$$;
>

This is not the same command as originally presented, in particular this
uses myparam as an identifier (which can never be a variable) while the
original used myparam as a value (which usually can be a variable). That
said I'm not sure at the moment where exactly the breakdown is that results
in myparam being checked as a column name (and thus not found) instead of
as a variable name (and thus found and replaced with a literal, which
SELECT can handle just fine).

If COPY itself can be parameterized/prepared (I'm unsure and not able to
test right now) then it should be able to accept variables when used in a
function - within the rules for variable substitution.

David J.

As an aside, the format() combined with EXECUTE in pl/pgsql is much more
readable as well as makes preventing SQL injection trivial.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-03-10 16:46:51 Re: COPY TO (query) allows no function arguments
Previous Message Joe Conway 2021-03-10 15:17:07 Re: COPY TO (query) allows no function arguments