Re: [HACKERS] Escape handling in strings

2005-06-21 Thread Tom Lane
Oliver Jowett [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] Escape handling in strings

2005-06-21 Thread Tom Lane
AgentM [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] Escape handling in strings

2005-06-21 Thread Bruce Momjian
Tom Lane wrote:
 Oliver Jowett [EMAIL PROTECTED] 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, Pennsylvania 19073

---(end of broadcast)---
TIP 8: explain analyze is your friend


[HACKERS] Escape handling in strings

2005-06-20 Thread Bruce Momjian
[ 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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] Escape handling in strings

2005-06-20 Thread Oliver Jowett
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

---(end of broadcast)---
TIP 8: explain analyze is your friend