From: | Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql command for bytea output |
Date: | 2011-10-21 19:07:13 |
Message-ID: | 4EA1C2E1.3040202@pgexperts.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/21/2011 02:51 PM, Pavel Stehule wrote:
> 2011/10/21 Andrew Dunstan<andrew(dot)dunstan(at)pgexperts(dot)com>:
>> On 10/21/2011 02:44 PM, Pavel Stehule wrote:
>>> 2011/10/21 Andrew Dunstan<andrew(dot)dunstan(at)pgexperts(dot)com>:
>>>> A few months ago, I blogged about the difficulty of getting psql to put a
>>>> bytea datum into a file. See
>>>>
>>>> <http://people.planetpostgresql.org/andrew/index.php?/archives/196-Clever-trick-challenge.html>.
>>>> Today I ran into the problem again, and it struck me that we could fairly
>>>> easily have a new command to handle this, called, say, bcopy. So it would
>>>> look like:
>>>>
>>>> \bcopy (select generate_bytea()) to foo.bin
>>>>
>>>>
>>>> Thoughts?
>>> isn't better to fix current tools to work well with bytea?
>>>
>> Such as?
> some like
>
> \copy ... to foo.bin format binary
>
> a COPY API can do it - it support a binary load and binary dump, so
> just there is missing interface
>
That would be fine if you could suppress the file header/trailer and
field header, so all you got was the raw data. But making COPY do that
seems no cleaner than what I suggested.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-10-21 19:07:26 | Re: So, is COUNT(*) fast now? |
Previous Message | Pavel Stehule | 2011-10-21 18:51:39 | Re: psql command for bytea output |