Christopher Kings-Lynne wrote:
> > * 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. However,
> >
Tom Lane wrote:
> What we are talking about here is an extremely significant change with
> extremely serious consequences, and imagining that it is not will be
> a recipe for disaster.
>
> I also think that pgsql-patches is not the place to be discussing such
> things... it needs a whole lot more
Rod Taylor <[EMAIL PROTECTED]> writes:
> It probably won't be any worse than when '' was rejected for an integer
> 0.
That analogy is *SO* far off the mark that I have to object.
Fooling with quoting rules will not simply cause clean failures, which
is what you got from ''-no-longer-accepted-by-a
Pavel Stehule <[EMAIL PROTECTED]> writes:
> what is wrong on GUC?
The idea of a GUC that allows security violations when it's set
differently than the application is expecting fills me with fear.
This is going to look the 7.3 autocommit fiasco look like a day
at the beach.
>
> Why not compromise? Allow ONLY \' in normal strings? That'd deal with
> the majority of compatibility issues. Or, like you say, make it a GUC :(
>
> Chris
>
what is wrong on GUC?
Pavel
---(end of broadcast)---
TIP 6: Have you searched o
On Wed, 2005-06-15 at 23:13 -0400, Bruce Momjian wrote:
> Sorry, one more thing. :-(
>
> Let me add that I am not 100% sold on the idea either, but using the
> logic I outlined, I don't see how we can continue to do nothing about
> this issue, and I am afraid delay will only make an inevitable fi
* 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. However,
disabling backslashes cou
Sorry, one more thing. :-(
Let me add that I am not 100% sold on the idea either, but using the
logic I outlined, I don't see how we can continue to do nothing about
this issue, and I am afraid delay will only make an inevitable fix
harder. Maybe we will have to wait 2-3 years before we can mak
Christopher Kings-Lynne wrote:
> > Yep, you probably are. The hurt is backward compatibility, but the gain
> > is greater portability with other database systems.
>
> It's just going to break millions of PHP scripts :(
Let me give you a little longer answer. Right now we have this TODO
item:
Yep, you probably are. The hurt is backward compatibility, but the gain
is greater portability with other database systems.
It's just going to break millions of PHP scripts :(
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe comm
Christopher Kings-Lynne wrote:
> I'm still really iffy about this. I think it will really hurt pgsql due
> to backward compatibility :(
>
> (If I'm understanding how the proposed change works...)
Yep, you probably are. The hurt is backward compatibility, but the gain
is greater portability wit
I'm still really iffy about this. I think it will really hurt pgsql due
to backward compatibility :(
(If I'm understanding how the proposed change works...)
Chris
Bruce Momjian wrote:
A summary of my proposal to add a new E'' string for escape and have
non-E escapes not handle backslashes s
12 matches
Mail list logo
