Re: psql command for bytea output - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: psql command for bytea output
Date
Msg-id 4EA1E26B.2050700@pgexperts.com
Whole thread Raw
In response to Re: psql command for bytea output  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: psql command for bytea output  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: psql command for bytea output
Next
From: Robert Haas
Date:
Subject: Re: psql \set vs \copy - bug or expected behaviour?