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: 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

In response to

Responses

Browse pgsql-hackers by date

  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