2016-11-10 18:56 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>:
> 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.)
>
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 :(
Pavel
>
> regards, tom lane
>
