Pavel Stehule <pavel.steh...@gmail.com> writes: > 2016-11-09 22:47 GMT+01:00 Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers