From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: copybytea command for psql |
Date: | 2012-02-16 21:11:30 |
Message-ID: | 4F3D7102.2000303@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/16/2012 03:32 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> A while ago I went looking for nice ways to export an unencoded bytea
>> value using psql, see
>> <http://people.planetpostgresql.org/andrew/index.php?/archives/196-Clever-trick-challenge.html>.
>> Regina Obe is also in want of a solution for this:
>> <http://www.postgresonline.com/journal/archives/243-PSQL-needs-a-better-way-of-outputting-bytea-to-binary-files.html>.
>> It seems like what we need is a psql command for it, something like:
>> \copybytea (select query_returning_one_bytea) to /path/to/file
>> Does anyone have a better solution or any objection to this feature?
> It seems awfully narrow. In the first place, why restrict it to bytea?
> In the second, that syntax is going to cause serious headaches, not
> least because backslash commands can't extend across multiple lines.
>
> The idea that comes to mind for me, if you want to connect this up to
> SELECT and not COPY, is some variant of \g that implies (1) pull back
> the data as binary not text, and (2) dump it to the target file with
> absolutely no recordseps, fieldseps, etc; just the bytes, ma'am.
>
> It might be worth thinking of (1) and (2) as separately invokable
> features, or then again it might not. I also wonder how this might
> interact with Peter E's recent commit for null-byte separators.
>
>
Oh, nice idea. say \g{bn} where b was for binary fetch/output and n was
for no recordseps etc?
That looks like a winner.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2012-02-16 21:11:56 | pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) |
Previous Message | Robert Haas | 2012-02-16 20:53:53 | Re: Command Triggers |