Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2016-11-09 22:47 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
>> * I really dislike the notion of keying the behavior to a special type of
>> psql variable.
> still I am thinking so some differencing can be nice, because we can use
> psql file path tab autocomplete.
> Maybe \setfileref can stay - it will set any variable, but the autocomplete
> will be based on file path.
Personally, I'd rather have filename tab completion after ":<", and forget
\setfileref --- I do not think that setting a variable first is going to
be the primary use-case for this. In fact, I could happily dispense with
the variable case entirely, except that sometimes people will want to
reference file names that don't syntactically fit into the colon syntax
(eg, names with spaces in them). Even that seems surmountable, if people
are okay with requiring the '<' trailer --- I don't think we need to worry
too much about supporting file names with '<' in them. (Likewise for
'>', if you feel like :<filename> is a less ugly syntax.)
> What do you thing about following example?
> INSERT INTO tab VALUES(1, :<varname); -- insert text value -- used text
> escaping
> INSERT INTO tab VALUES(1, :<#varname); -- insert bytea value -- used bytea
> escaping
Seems a bit arbitrary, and not readily extensible to more datatypes.
I guess an advantage of the parameterized-query approach is that we
wouldn't really have to distinguish different datatypes in the syntax,
because we could use the result of Describe Statement to figure out what
to do. Maybe that outweighs the concern about magic behavioral changes.
On the other hand, it's also arguable that trying to cater for automatic
handling of raw files as bytea literals is overcomplicating the feature
in support of a very infrequent use-case, and giving up some other
infrequent use-cases to get that. An example is that if we insist on
doing this through parameterized queries, it will not work for inserting
literals into utility commands. I don't know which of these things is
more important to have.
regards, tom lane