Обсуждение: Escape handling in strings

[ BCC to general. ]

I have received very few replies to my suggestion that we implement E''
for escaped strings, so eventually, after a few major releases, we can
have '' treat backslashes literally like the SQL standard requires.

I assume this is because most people say, "yea, it is going to be a pain,
and yea, we should probably do it".

A summary of the plan is at:

    http://candle.pha.pa.us/cgi-bin/pgescape

Therefore, I will soon apply the escape patch at:

    ftp://candle.pha.pa.us/pub/postgresql/mypatches/escape

I will also backpatch the E'' syntax and read-only GUC variables to
earlier releases.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

> I have received very few replies to my suggestion that we implement E''
> for escaped strings, so eventually, after a few major releases, we can
> have '' treat backslashes literally like the SQL standard requires.

Just checking: with this plan, a client needs to know what server
version is in use to correctly escape strings, correct? That is, there
is no escape mechanism that works correctly for both "old" and "new"
servers?

-O

Oliver Jowett <oliver@opencloud.com> writes:
> Bruce Momjian wrote:
>> I have received very few replies to my suggestion that we implement E''
>> for escaped strings, so eventually, after a few major releases, we can
>> have '' treat backslashes literally like the SQL standard requires.

> Just checking: with this plan, a client needs to know what server
> version is in use to correctly escape strings, correct? That is, there
> is no escape mechanism that works correctly for both "old" and "new"
> servers?

When the change happens, yes, it will be non compatible.  I don't
recommend thinking of it as a "server version" check though --- we
will put in a read-only GUC variable (like the one for integer
datetimes) and you can check it through the parameter reporting
mechanism.
        regards, tom lane

What I am really hoping for is that PQexecParams() [in later versions  
of libpq] can figure it out for itself so client code doesn't need  
fixing. That is the plan, right?

On Jun 20, 2005, at 11:57 PM, Oliver Jowett wrote:

> Bruce Momjian wrote:
>
>
>> I have received very few replies to my suggestion that we  
>> implement E''
>> for escaped strings, so eventually, after a few major releases, we  
>> can
>> have '' treat backslashes literally like the SQL standard requires.
>>
>
> Just checking: with this plan, a client needs to know what server
> version is in use to correctly escape strings, correct? That is, there
> is no escape mechanism that works correctly for both "old" and "new"
> servers?


|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
AgentM
agentm@themactionfaction.com
|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

FYI

On 06/20/2005 11:12:20 PM, Bruce Momjian wrote:
> [ BCC to general. ]
> 
> I have received very few replies to my suggestion that we implement
> E''
> for escaped strings, so eventually, after a few major releases, we can
> have '' treat backslashes literally like the SQL standard requires.
> 
> I assume this is because most people say, "yea, it is going to be a
> pain,
> and yea, we should probably do it".
> 
> A summary of the plan is at:
> 
>     http://candle.pha.pa.us/cgi-bin/pgescape

To my mind your recommendation for 8.3  8.3 - Have non-'E' strings treat backslashes literally.
would require a major version change, to 9.0 instead of
8.3, as it breaks forward and backward compatability.

But that's just the way I see version numbering working,
not necessarly how postgresql does it.


Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."                 -- Robert A. Heinlein

AgentM <agentm@themactionfaction.com> writes:
> What I am really hoping for is that PQexecParams() [in later versions  
> of libpq] can figure it out for itself so client code doesn't need  
> fixing. That is the plan, right?

Out-of-line parameters are not an issue at all --- only string literals
embedded in the SQL query.
        regards, tom lane

Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> writes:
> > Bruce Momjian wrote:
> >> I have received very few replies to my suggestion that we implement E''
> >> for escaped strings, so eventually, after a few major releases, we can
> >> have '' treat backslashes literally like the SQL standard requires.
> 
> > Just checking: with this plan, a client needs to know what server
> > version is in use to correctly escape strings, correct? That is, there
> > is no escape mechanism that works correctly for both "old" and "new"
> > servers?
> 
> When the change happens, yes, it will be non compatible.  I don't
> recommend thinking of it as a "server version" check though --- we
> will put in a read-only GUC variable (like the one for integer
> datetimes) and you can check it through the parameter reporting
> mechanism.

Right, the GUC read-only variables are already in the patch URL I
posted.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073