Re: proposal: psql \setfileref - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: proposal: psql \setfileref
Date
Msg-id 16ab2256-636d-48a0-911b-bc510b53cb3f@mm
Whole thread Raw
In response to Re: proposal: psql \setfileref  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: proposal: psql \setfileref  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
    Corey Huinker wrote:

> I am not asking for this feature now, but do you see any barriers to later
> adding x/xq/xb/xbq equivalents for executing a shell command?

For text contents, we already have this (pasted right from the doc):

testdb=> \set content `cat my_file.txt`
testdb=> INSERT INTO my_table VALUES (:'content');

Maybe we might look at why it doesn't work for binary string and fix that?

I can think of three reasons:

- psql use C-style '\0' terminated string implying no nul byte in variables.
That could potentially be fixed by tweaking the data structures and
accessors.

- the backtick operator trims ending '\n' from the result of the command
(like the shell), but we could add a variant that doesn't have this behavior.

- we don't have "interpolate as binary", an operator that will
essentially apply PQescapeByteaConn rather than PQescapeStringConn.

For example, I'd suggest this syntax:

-- slurp a file into a variable, with no translation whatsoever
\set content ``cat my_binary_file``

-- interpolate as binary (backquotes instead of quotes)
INSERT INTO my_table VALUES(:`content`);

If we had something like this, would we still need filerefs? I feel like
the point of filerefs is mainly to work around lack of support for
binary in variables, but maybe supporting the latter directly would
be an easier change to accept.


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Something is broken about connection startup
Next
From: Robert Haas
Date:
Subject: Re: Logical Replication WIP