Lists: | pgsql-hackers |
---|
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | proposal: copybytea command for psql |
Date: | 2012-02-16 20:06:02 |
Message-ID: | 4F3D61AA.5000209@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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?
cheers
andrew
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: copybytea command for psql |
Date: | 2012-02-16 20:32:13 |
Message-ID: | 15094.1329424333@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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.
regards, tom lane
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 |
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: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: copybytea command for psql |
Date: | 2012-02-24 18:26:03 |
Message-ID: | 1330107963.32452.17.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On tor, 2012-02-16 at 16:11 -0500, Andrew Dunstan wrote:
> Oh, nice idea. say \g{bn} where b was for binary fetch/output and n
> was for no recordseps etc?
Why not set the record separator to ''?