dbTalk Databases Forums  

Re: [BUGS] BUG #1350: Backslash ecape charcter violates ISO/ANSI

mailing.database.pgsql-bugs mailing.database.pgsql-bugs


Discuss Re: [BUGS] BUG #1350: Backslash ecape charcter violates ISO/ANSI in the mailing.database.pgsql-bugs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Ken Johanson
 
Posts: n/a

Default Re: [BUGS] BUG #1350: Backslash ecape charcter violates ISO/ANSI - 12-17-2004 , 04:23 PM







Quote:
We have a TODO item:

* Allow backslash handling in quoted strings to be disabled for
portability

The use of C-style backslashes (.e.g. \n, \r) in quoted strings is not
SQL-spec compliant, so allow such handling to be disabled.

Unfortunately that's all we have. :-)



Thanks, glad to hear it's on the radar. From what I can tell it the
broadest reaching standards incompatibility in the server. And, it's
preventing some project managers from adopting the server as an
alternative to the commercial ones (Its always been an easy-to-cite, and
well justified concern that the backslash behavior is incompatible with
other DBs and specs).

Thx,
ken




---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html


Reply With Quote
  #2  
Old   
Bruce Momjian
 
Posts: n/a

Default Re: [BUGS] BUG #1350: Backslash ecape charcter violates ISO/ANSI - 12-17-2004 , 09:54 PM






Ken Johanson wrote:
Quote:
We have a TODO item:

* Allow backslash handling in quoted strings to be disabled for
portability

The use of C-style backslashes (.e.g. \n, \r) in quoted strings is not
SQL-spec compliant, so allow such handling to be disabled.

Unfortunately that's all we have. :-)



Thanks, glad to hear it's on the radar. From what I can tell it the
broadest reaching standards incompatibility in the server. And, it's
That is probably true.

Quote:
preventing some project managers from adopting the server as an
alternative to the commercial ones (Its always been an easy-to-cite, and
well justified concern that the backslash behavior is incompatible with
other DBs and specs).
We don't hear it very often, perhaps once every four months. You have
to double single quotes from user data anyway so most of our interfaces
have a function that does this and handles backslashes too.

Our TODO list probably has even more items you could cite as reasons
_not_ to use PostgreSQL. :-) When it becomes a key issue for someone I
suppose they will code a fix for it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) 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 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org


Reply With Quote
  #3  
Old   
Ken Johanson
 
Posts: n/a

Default Re: [BUGS] BUG #1350: Backslash ecape charcter violates ISO/ANSI - 12-18-2004 , 01:01 AM




Quote:
We don't hear it very often, perhaps once every four months. You have
to double single quotes from user data anyway so most of our interfaces
have a function that does this and handles backslashes too.



True, but users also need (or already use) a generic, predictable
SQL-escape function (mere apostrophe doubling) from their API, that
needs to work for any database..., but when they try to use it with pg,
they are blindsided when they realize backslash characters are lost (I
know of one company that committed to PG and had to back out after they
eventually realized the backslash issue (porting issue) was too
burdensome for their large codebase - sad).

Unfortunately many APIs dont have the prepared statement style automatic
string escaping available; more importantly, prepared statements dont
work well some highly complex, programaticly generated SQL statements,
and a generic Sql escape function is far easier to use (in my experience).

Quote:
Our TODO list probably has even more items you could cite as reasons
_not_ to use PostgreSQL. :-) When it becomes a key issue for someone I
suppose they will code a fix for it.



I may have this key issue - user share.... the other large open source
DB is adding this compliance-mode at the request of SAP, so this will
leave postgres as the last one standing... so to speak. ;-) Since
incorrect SQL escaping has been a key reservation about (both) these DBs
for users in transition (from commercial DBs), this last mile of
compliance (of this magnitude) will benefit its benefactor with the
market share of those awaiting masses :-)



---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.