From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
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:27:58 |
Message-ID: | 16174.1319228878@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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 ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-10-21 20:37:16 | Re: [PATCH] Log crashed backend's query v3 |
Previous Message | Robert Haas | 2011-10-21 20:24:12 | Re: So, is COUNT(*) fast now? |