From: | Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql command for bytea output |
Date: | 2011-10-21 21:21:47 |
Message-ID: | 4EA1E26B.2050700@pgexperts.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/21/2011 04:43 PM, Pavel Stehule wrote:
>
>> 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?
>
Well, my main use case is only for output of a single datum. Sure we
could run them all together on output, but it's hard to see what use
that would be unless everything were of fixed size.
Being able to load a single datum would certainly be good, and not just
for bytea fields - for any large piece of text as well, in fact. One use
case I have for that involves a number of fairly large XSL stylesheets
that need to be loaded into a database. Currently that's done via psql
variables, but it's a bit grotty.
I also think this is really just a psql issue. Most other clients (e.g.
a perl DBD::Pg client) will have no trouble handling all this now.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-10-21 21:31:41 | Re: psql \set vs \copy - bug or expected behaviour? |
Previous Message | Pavel Stehule | 2011-10-21 20:43:12 | Re: psql command for bytea output |