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'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.
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.
Maybe using extended mode could be driven off a setting rather than being
identified by syntax? 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
