[HACKERS] Re: new set of psql patches for loading (saving) data from (to) text,binary files - Mailing list pgsql-hackers

From Pavel Stehule
Subject [HACKERS] Re: new set of psql patches for loading (saving) data from (to) text,binary files
Date
Msg-id CAFj8pRDKVUBS6ALbv7KgoWZrtMvrUgpSeNEgEbnYprVTe4i+8g@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Re: new set of psql patches for loading (saving) data from (to)text, binary files  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers


2017-03-16 22:01 GMT+01:00 Stephen Frost <sfrost@snowman.net>:
Pavel,

* Pavel Stehule (pavel.stehule@gmail.com) wrote:
> 2017-03-15 17:21 GMT+01:00 Stephen Frost <sfrost@snowman.net>:
> > I started looking through this to see if it might be ready to commit and
> > I don't believe it is.  Below are my comments about the first patch, I
> > didn't get to the point of looking at the others yet since this one had
> > issues.
> >
> > * Pavel Stehule (pavel.stehule@gmail.com) wrote:
> > > 2017-01-09 17:24 GMT+01:00 Jason O'Donnell <odonnelljp01@gmail.com>:
> > > > gstore/gbstore:
> >
> > I don't see the point to 'gstore'- how is that usefully different from
> > just using '\g'?  Also, the comments around these are inconsistent, some
> > say they can only be used with a filename, others say it could be a
> > filename or a pipe+command.
>
> \gstore ensure dump row data. It can be replaced by \g with some other
> setting, but if query is not unique, then the result can be messy. What is
> not possible with \gbstore.

I don't understand what you mean by "the result can be messy."  We have
lots of options for controlling the output of the query and those can be
used with \g just fine.  This seems like what you're doing is inventing
something entirely new which is exactly the same as setting the right
options which already exist and that seems odd to me.

Is it any different from setting \a and \t and then calling \g?  If not,
then I don't see why it would be useful to add.

I am searching some comfortable way - I agree, it can be redundant to already available functionality. 
 

> More interesting is \gbstore that uses binary API - it can be used for
> bytea fields or for XML fields with implicit correct encoding change.
> \gbstore is not possible to replace by \g.

Yes, having a way to get binary data out using psql and into a file is
interesting and I agree that we should have that capability.

Further, what I think we will definitely need is a way to get binary
data out using psql at the command-line too.  We have the -A and -t
switches which correspond to \a and \t, we should have something for
this too.  Perhaps what that really calls for is a '\b' and a '-B'
option to go with it which will flip psql into binary mode, similar to
the other Formatting options.  I realize it might seem a bit
counter-intuitive, but I can actually see use-cases for having binary
data spit out to $PAGER (when you have a $PAGER that handles it
cleanly, as less does, for example).

It is interesting idea. I am not sure if it is more formatting option or general psql option. But can be interesting for another purposes too. 

One idea for import files to postgres via psql

we can introduce \gloadfrom that can replace parameters by files - and this statement can work in text or in binary mode controlled by proposed option.

some like

insert into foo values('Pavel','Stehule', $1) \gloadfrom ~/avatar.jpg
insert into doc(id, doc) values(default, $1) \gloadfrom ~/mydoc.xml

Regards

Pavel
 

> > There's a whitespace-only hunk that shouldn't be included.
> >
> > I don't agree with the single-column/single-row restriction on these.  I
> > can certainly see a case where someone might want to, say, dump out a
> > bunch of binary integers into a file for later processing.
> >
> > The tab-completion for 'gstore' wasn't correct (you didn't include the
> > double-backslash).  The patch also has conflicts against current master
> > now.
> >
> > I guess my thinking about moving this forward would be to simplify it to
> > just '\gb' which will pull the data from the server side in binary
> > format and dump it out to the filename or command given.  If there's a
> > new patch with those changes, I'll try to find time to look at it.
>
> ok I'll prepare patch

Great, thanks!

Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Candidate for local inline function?
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] increasing the default WAL segment size