Re: psql command for bytea output

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

In response to

Browse pgsql-hackers by date

  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