From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql command for bytea output |
Date: | 2011-10-21 20:43:12 |
Message-ID: | CAFj8pRBdvjKB4D20Oe4VHY5TxvYKrhceLoe+1VKq7xamOi_KiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/10/21 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2011/10/21 Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com>:
>>> On 10/21/2011 02:44 PM, Pavel Stehule wrote:
>>>> isn't better to fix current tools to work well with bytea?
>
>>> Such as?
>
>> some like
>> \copy ... to foo.bin format binary
>
> No, because COPY BINARY will emit its own sort of wrappers around the
> data.
true - it's not useful for this case
>
> What I don't like about Andrew's proposal is that it seems rather
> limited. Why bytea in particular? Text chunks could probably also use
> a direct output method. And what about input?
>
> Could we do anything with a notion of a COPY RAW mode, that would dump
> or read the data without any header, column, or row separators? On
> input I suppose you'd have to restrict it to one column --- on output,
> we could leave re-dividing the data to the user's ingenuity ...
>
+1
Andrew - has sense a input/output different than 1row/1column?
Regards
Pavel
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-10-21 21:21:47 | Re: psql command for bytea output |
Previous Message | Robert Haas | 2011-10-21 20:40:23 | Re: [PATCH] Log crashed backend's query v3 |