Pavel Stehule <pavel.stehule@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.