Skip site navigation (1) Skip section navigation (2)

Re: Missing ParameterStatus for backslash_quote

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paesold <mpaesold(at)gmx(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Missing ParameterStatus for backslash_quote
Date: 2006-11-27 00:22:51
Message-ID: 285.1164586971@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Michael Paesold <mpaesold(at)gmx(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-11-27 00:32:20
Subject: Re: [PATCHES] Avg performance for int8/numeric
Previous:From: Peter EisentrautDate: 2006-11-26 23:50:24
Subject: Re: [CORE] RC1 blocker issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group