Skip site navigation (1) Skip section navigation (2)

Re: proposal: copybytea command for psql

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 (view raw or flat)
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


In response to

Responses

pgsql-hackers by date

Next:From: Peter GeogheganDate: 2012-02-16 21:11:56
Subject: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Previous:From: Robert HaasDate: 2012-02-16 20:53:53
Subject: Re: Command Triggers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group