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.)
In this case I dislike '>' on the end. The semantic is less clear with it.
I though about dropping variables too, but I expecting a expandable variable after colon syntax. So it need special clear syntax for disabling variable expansion.
What about :<{filename} ?
INSERT INTO tab VALUES(1, :<{~/data/doc.txt});
> 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.
there are only two possibilities - text with client encoding to server encoding conversions, and binary - without any conversions.
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.
I don't understand - there is a possibility to detect type of parameter on client side?
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.
I had not idea a complete replacement of current mechanism by query parameters. But a partial usage can be source of inconsistencies :(