Re: Re: new set of psql patches for loading (saving) data from (to) text, binary files

2017-04-06 14:47 GMT+02:00 Stephen Frost <sfrost(at)snowman(dot)net>:

> Greetings,
>
> * Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
> > 2017-04-06 3:34 GMT+02:00 Stephen Frost <sfrost(at)snowman(dot)net>:
> > > Having the template not require the row/column place-holders included
> > > strikes me as more likely to be confusing. My initial thinking around
> > > this was that users who actually want independent files would simply
> > > issue independent queries, while users who want to take a bunch of int4
> > > columns and dump them into a single binary file would be able to do so
> > > easily.
> > >
> > > I'm not against adding the ability for a single query result to be
> saved
> > > into independent files, but it strikes me as feature creep on this
> basic
> > > capability. Further, I don't see any particular reason why splitting
> up
> > > the output from a query into multiple files is only relevant for binary
> > > data.
> >
> > The files can be simply joined together outside psql
>
> Just as multiple queries could be done to have the results put into
> independent files.
>
> > Personally I prefer relation type: single field, single file in special
> g
> > command - because I can simply off all formatting and result should be
> > correct every time.
>
> Not sure why you think there would be a formatting issue or why the
> result might not be 'correct'.
>
> > Stephen, have you some use case for your request?
>
> The initial patch forced a single value result. Including such a
> restriction doesn't seem necessary to me. As for use-case, I've
> certainly written code to work with binary-result data from PG
> previously and it seems entirely reasonable that someone might wish to
> pull data into a file with psql and then process it. I've been
> wondering if we should consider how binary-mode COPY works, but that
> format ends up being pretty inefficient due to the repeated 32-bit
> length value for every field.
>
> My initial reaction was primairly that I didn't see value in the
> somewhat arbitrary restriction being imposed on usage of this.
>

ok.

It is hard to design any solution - because there are not any intersection
on this basic simple things.

Regards

Pavel

>
> Thanks!
>
> Stephen
>