Обсуждение: Missing ParameterStatus for backslash_quote

Поиск
Список
Период
Сортировка

Missing ParameterStatus for backslash_quote

От
Michael Paesold
Дата:
While trying to finish the support for standard_conforming_strings in 
the JDBC driver, I realized that there is also a new variable 
"backslash_quote" that controls whether a back-slash may be used to 
escape a single quote inside a string constant.

Assuming the documentation is correct, this variable is not reported via 
ParameterStatus messages.
http://developer.postgresql.org/pgdocs/postgres/protocol-flow.html#PROTOCOL-ASYNC

This is a problem for the query parsing code inside the JDBC driver 
because it needs to know about the state of this variable so that 
parsing a query in the driver has the same result as in the backend.

I therefore ask to add backslash_quote to the hardcoded list of 
variables that are reported via ParameterStatus in 8.2 as well as all 
back-branches that support V3 as well as the backslash_quote variable 
(7.4, 8.0, 8.1, I guess).

Best Regards
Michael Paesold


Re: Missing ParameterStatus for backslash_quote

От
Tom Lane
Дата:
Michael Paesold <mpaesold@gmx.at> writes:
> Assuming the documentation is correct, this variable is not reported via 
> ParameterStatus messages.

That's intentional.  There is no reason for an application to need to
know about that variable, because there is no reason for it to change
behavior in consequence.  Applications shouldn't be using backslash-quote,
period -- quote-quote is always correct instead.

> This is a problem for the query parsing code inside the JDBC driver 
> because it needs to know about the state of this variable so that 
> parsing a query in the driver has the same result as in the backend.

I don't see that the JDBC driver needs to know about it either.
Changing the setting only causes an error to be reported (or not) ---
it does not affect the meaning of a string.  Also, the default setting
won't affect JDBC because JDBC only uses client_encoding = UTF8.  AFAICS
JDBC can assume that backslash-quote is legal and the backend will
reject it if not.

> I therefore ask to add backslash_quote to the hardcoded list of 
> variables that are reported via ParameterStatus in 8.2 as well as all 
> back-branches that support V3 as well as the backslash_quote variable 
> (7.4, 8.0, 8.1, I guess).

If we did do that, you still couldn't rely on knowing the value, because
there are backends in the field that won't tell you about it.
        regards, tom lane


Re: Missing ParameterStatus for backslash_quote

От
Michael Paesold
Дата:
Tom Lane wrote:
> Michael Paesold <mpaesold@gmx.at> writes:
>> Assuming the documentation is correct, this variable is not reported via 
>> ParameterStatus messages.
> 
> That's intentional.  There is no reason for an application to need to
> know about that variable, because there is no reason for it to change
> behavior in consequence.  Applications shouldn't be using backslash-quote,
> period -- quote-quote is always correct instead.

FWIW, I am just changing the JDBC driver to use quote-quote instead of 
backslash-quote in the cases where the driver does escaping. I think 
this should be back-patched to all supported branches.

>> This is a problem for the query parsing code inside the JDBC driver 
>> because it needs to know about the state of this variable so that 
>> parsing a query in the driver has the same result as in the backend.
> 
> I don't see that the JDBC driver needs to know about it either.
> Changing the setting only causes an error to be reported (or not) ---
> it does not affect the meaning of a string.  Also, the default setting
> won't affect JDBC because JDBC only uses client_encoding = UTF8.  AFAICS
> JDBC can assume that backslash-quote is legal and the backend will
> reject it if not.

You are absolutely right. I was fooled by, e.g. the string constant 
'C:\'. With standard_conforming_strings on, this is legal, 
backslash-quote is not considered anyways. But without standard 
conforming strings, this is illegal anyways, because it should have read 
'C:\\'.

So less work for me. :-)

Thanks, Tom.

Best Regards
Michael Paesold