2016-11-16 17:58 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>:

> Pavel Stehule <pavel.steh...@gmail.com> writes:
> > The Daniel's proposal has important issues:
> > 1. you need to store and hold the content in memory
> > 2. you cannot use tab complete - without it this feature lost a usability
> > 3. you have to do two steps
> > 4. Depends on o.s.
> I think you're putting *way* too much emphasis on tab completion of the
> filename.  That's a nice-to-have, but it should not cause us to contort

the feature design to get it.

I am sorry, I cannot to agree. When you cannot use tab complete in
interactive mode, then you lost valuable help.

> I'm not especially impressed by objections 3 and 4, either.  Point #1
> has some merit, but since the wire protocol is going to limit us to
> circa 1GB anyway, it doesn't seem fatal.

There are not "cat" on ms win. For relative basic functionality you have to
switch between platforms.

> What I like about Daniel's proposal is that because it adds two separate
> new behaviors, it can be used for more things than just "interpolate a
> file".  What I don't like is that we're still stuck in the land of textual
> interpolation into query strings, which as you noted upthread is not
> very user-friendly for long values.  I thought there was some value in
> your original idea of having a way to get psql to use extended query mode
> with the inserted value being sent as a parameter.  But again, I'd rather
> see that decoupled as a separate feature and not tightly tied to the
> use-case of interpolating a file.

With content commands syntax, I am able to control it simply - there is
space for invention of new features.

the my patch has full functionality of Daniel's proposal

\set xxx {rb somefile} - is supported already in my last patch

Now I am working only with real files, but the patch can be simply extended
to work with named pipes, with everything. There is a space for extending.

> Maybe using extended mode could be driven off a setting rather than being
> identified by syntax?

It is possible, but I don't think so it is user friendly - what is worst -
use special syntax or search setting some psql set value?

> There doesn't seem to be much reason why you'd want
> some of the :-interpolated values in a query to be inlined and others sent
> as parameters.  Also, for testing purposes, it'd be mighty nice to have a
> way of invoking extended query mode in psql with a clear way to define
> which things are sent as parameters.  But I don't want to have to make
> separate files to contain the values being sent.
>                         regards, tom lane

Reply via email to