Robert Haas wrote:
On Wed, Feb 3, 2010 at 5:57 PM, Andrew Dunstan wrote:
marcin mank wrote:
A certain prominent web framework has a nasty SQL injection bug when
PG is configured with SCS. This bug is not present without SCS
(details per email for interested PG hackers). I say, hold i
On Feb 3, 2010, at 6:16 PM, Robert Haas wrote:
>> Any web framework that interpolates user supplied values into SQL rather
>> than using placeholders is broken from the get go, IMNSHO. I'm not saying
>> that there aren't reasons to hold up moving to SCS, but this isn't one of
>> them.
>
> That se
On Wed, Feb 3, 2010 at 5:57 PM, Andrew Dunstan wrote:
> marcin mank wrote:
>> A certain prominent web framework has a nasty SQL injection bug when
>> PG is configured with SCS. This bug is not present without SCS
>> (details per email for interested PG hackers). I say, hold it off.
>
> Any web fra
marcin mank wrote:
A certain prominent web framework has a nasty SQL injection bug when
PG is configured with SCS. This bug is not present without SCS
(details per email for interested PG hackers). I say, hold it off.
Any web framework that interpolates user supplied values into SQL rath
A certain prominent web framework has a nasty SQL injection bug when
PG is configured with SCS. This bug is not present without SCS
(details per email for interested PG hackers). I say, hold it off.
Greetings
Marcin Mańk
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Josh Berkus writes:
>> I still think that changing it now is going to open a can of worms that
>> we shouldn't be opening at this stage. We have got more than enough to
>> worry about for 9.0 already. I think it is absolute folly to believe
>> that this is only going to be a matter of "flip the
Tom Lane writes:
> And that's just for the core code. I don't want to blindside driver
> writers and other third-party authors with a change like this made at
> the end of the cycle. If we do it at the beginning of the 9.1 devel
> cycle, no one will have room to argue that they didn't have adequ
On Wed, 03 Feb 2010 14:41:13 -0500, Tom Lane wrote:
> Indeed it is, which is one of the reasons to be cautious with changing
> it. We've been telling people to move away from \' for a long time,
> but actually flipping the switch that will make their apps insecure
> is not something to do on the
Mark Mielke writes:
> On 02/03/2010 01:20 PM, Robert Haas wrote:
>> I am not sure I really understand why anyone is a rush to make this
>> change.
> For myself, it isn't so much a rush as a sense that the code out there
> that will break, will never change unless forced, and any time seems
> be
On Wed, Feb 3, 2010 at 2:25 PM, Mark Mielke wrote:
> On 02/03/2010 01:20 PM, Robert Haas wrote:
>> I am not sure I really understand why anyone is a rush to make this
>> change. What harm is being done by the status quo? What benefit do
>> we get out of changing the default? The major argument
Rod Taylor escribió:
> As much as I would like GUCs to disappear I think this one should
> proceed cautiously and probably be a 9.1 or even 9.2 item.
Note that this is *not* about removing the configuration setting, only
about flipping its default value. There has been *no* talk of removing
the
On 02/03/2010 02:15 PM, Robert Haas wrote:
The longer we wait before making an
incompatible change, the more people will have adjusted their code to
the new reality (or upgraded their drivers, etc.) and the fewer things
will break.
In my experience, the opposite is true, although in this ca
On 02/03/2010 01:20 PM, Robert Haas wrote:
I am not sure I really understand why anyone is a rush to make this
change. What harm is being done by the status quo? What benefit do
we get out of changing the default? The major argument that has been
offered so far is that "if we don't change it n
"Greg Sabino Mullane" writes:
> Which fallout are we still dealing with? Are you saying that the
> developers are not up to the challenge of handling this before 9.0
> is released? (If this were anything more than a simple boolean GUC
> fix, I would be in your corner).
I'm not certain that Robert
On Wed, Feb 3, 2010 at 1:46 PM, Greg Sabino Mullane wrote:
>>> Perl (DBD::Pg anyway) has been compatible since May 2008.
>
>> I would interpret that to mean that there is a significant possibility
>> that a too-old DBD::Pg could get used with a new PostgreSQL, and
>> therefore we shouldn't change
> I still think that changing it now is going to open a can of worms that
> we shouldn't be opening at this stage. We have got more than enough to
> worry about for 9.0 already. I think it is absolute folly to believe
> that this is only going to be a matter of "flip the default and nothing
> el
On Wed, Feb 3, 2010 at 13:20, Robert Haas wrote:
> On Wed, Feb 3, 2010 at 12:34 PM, Greg Sabino Mullane
> wrote:
>> Perl (DBD::Pg anyway) has been compatible since May 2008.
>
> I would interpret that to mean that there is a significant possibility
> that a too-old DBD::Pg could get used with a
Alvaro Herrera writes:
> Tom Lane wrote:
>> The argument for doing this now hinges solely on a marketing-driven
>> choice of version name, and not on any actual evidence that applications
>> are ready for it. We really need to do this at the start of a devel
>> and alpha test cycle, not at the en
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> Perl (DBD::Pg anyway) has been compatible since May 2008.
> I would interpret that to mean that there is a significant possibility
> that a too-old DBD::Pg could
Robert Haas wrote:
> What harm is being done by the status quo? What benefit do
> we get out of changing the default?
I really think that the biggest harm is that people trying to
convert to PostgreSQL, or testing PostgreSQL with their
applications, can get bad behavior from use of standard s
Tom Lane wrote:
> The argument for doing this now hinges solely on a marketing-driven
> choice of version name, and not on any actual evidence that applications
> are ready for it. We really need to do this at the start of a devel
> and alpha test cycle, not at the end.
Application writers proba
On Wed, Feb 3, 2010 at 12:34 PM, Greg Sabino Mullane wrote:
> Perl (DBD::Pg anyway) has been compatible since May 2008.
I would interpret that to mean that there is a significant possibility
that a too-old DBD::Pg could get used with a new PostgreSQL, and
therefore we shouldn't change anything fo
* Tom Lane [100203 12:39]:
> "Greg Sabino Mullane" writes:
> > As one of the more vocal critics of the 8.3 implicit casting
> > incident, I say +1 on making the change. Unlike casting, it's
> > a simple GUC change to "fix", and now (9.0) is the time to
> > do it.
>
> Unfortunately, no: six month
"Greg Sabino Mullane" writes:
> As one of the more vocal critics of the 8.3 implicit casting
> incident, I say +1 on making the change. Unlike casting, it's
> a simple GUC change to "fix", and now (9.0) is the time to
> do it.
Unfortunately, no: six months ago was the time to do it.
The argument
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> The main problem of enabling standard_conforming_strings is
> that applications and/or programming language DB APIs are
> not prepared to support this. I don't see a change in DB
> APIs (that I know of -- Python, Perl, and PHP) to add
> suppor
Mark Mielke wrote:
> On 01/29/2010 09:01 PM, Tom Lane wrote:
> > Maybe. We concluded in the April 2009 thread that
> > standard_conforming_strings = ON had gotten little or no field testing,
> > and I don't see any strong reason to hope that it's gotten much more
> > since then.
>
> Not to contra
Euler Taveira de Oliveira writes:
> Peter Eisentraut escreveu:
>> Maybe the next step should be to leave standard_conforming_strings off
>> but make the warning an error.
>>
> It will break application in the same way as enabling the parameter. Besides
> that the parameter should be renamed to es
Peter Eisentraut escreveu:
> Maybe the next step should be to leave standard_conforming_strings off
> but make the warning an error.
>
It will break application in the same way as enabling the parameter. Besides
that the parameter should be renamed to escape_string_*error* to reflect the
fact that
Tom Lane wrote:
Cédric Villemain wrote:
>> Do you mean that turning standard_conforming_string ON may lead to
>> error with pg_dump, psql or something else ?
> Maybe. We concluded in the April 2009 thread that
> standard_conforming_strings = ON had gotten little or no field
> testing,
Well, we'
2010/1/30 Tom Lane :
> =?ISO-8859-1?Q?C=E9dric_Villemain?=
> writes:
>> 2010/1/29 Tom Lane :
>>> We would have more than no-time-at-all to test it and fix any breakage.
>>> Just to start close to home, do you really trust either psql or pg_dump
>>> to be completely free of standard_conforming_str
On fre, 2010-01-29 at 16:06 -0500, Bruce Momjian wrote:
> The way the docs stand now we hold it over people's heads and issue
> warnings that are meaningless if we are never going to change it.
Maybe the next step should be to leave standard_conforming_strings off
but make the warning an error.
On 01/29/2010 09:01 PM, Tom Lane wrote:
Maybe. We concluded in the April 2009 thread that
standard_conforming_strings = ON had gotten little or no field testing,
and I don't see any strong reason to hope that it's gotten much more
since then. It would be rather surprising if there *aren't* any
> An actual plan here might look like "let's flip it before 9.1alpha1
> so we can get some alpha testing cycles on it" ...
"Hey, let's flip it in 9.1 CF 1, so that we can have some alpha testing
cycles on it."
;-)
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> 2010/1/29 Tom Lane :
>> We would have more than no-time-at-all to test it and fix any breakage.
>> Just to start close to home, do you really trust either psql or pg_dump
>> to be completely free of standard_conforming_strings issues? How about
>> JDB
2010/1/29 Tom Lane :
> Josh Berkus writes:
>>> I stand by the position that it's way too late in the cycle for
>>> insufficiently-thought-out proposals for major behavioral changes.
>
>> I don't see how announcing this earlier in the dev cycle would help, at
>> all.
>
> We would have more than no-
On Friday 29 January 2010 23:47:22 Bruce Momjian wrote:
> Andres Freund wrote:
> > On Friday 29 January 2010 23:34:09 Tom Lane wrote:
> > > Josh Berkus writes:
> > > >> I stand by the position that it's way too late in the cycle for
> > > >> insufficiently-thought-out proposals for major behaviora
On Fri, Jan 29, 2010 at 5:44 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Well, since I asked in April of 2009, at the beginning of the cycle, 6
>> years after the introduction of the variable, and we still are not doing
>> it, then let's stop pretending we will ever do it.
>
> We have made for
> We would have more than no-time-at-all to test it and fix any breakage.
> Just to start close to home, do you really trust either psql or pg_dump
> to be completely free of standard_conforming_strings issues? How about
> JDBC or ODBC? Python drivers? PLs?
Oh, yeah. I was just thinking about
On Friday 29 January 2010 23:54:15 Tom Lane wrote:
> Andres Freund writes:
> > What about anouncing in the 9.0 releasenotes that it will be removed in
> > 9.1?
>
> That seems quite useless.
>
> I note that we've made such statements before and not followed through
> on them; one that just came u
Andres Freund writes:
> What about anouncing in the 9.0 releasenotes that it will be removed in 9.1?
That seems quite useless.
I note that we've made such statements before and not followed through
on them; one that just came up again is that contrib/xml2 is a couple
releases past when it was sa
Andres Freund wrote:
> On Friday 29 January 2010 23:34:09 Tom Lane wrote:
> > Josh Berkus writes:
> > >> I stand by the position that it's way too late in the cycle for
> > >> insufficiently-thought-out proposals for major behavioral changes.
> > >
> > > I don't see how announcing this earlier in
On Friday 29 January 2010 23:34:09 Tom Lane wrote:
> Josh Berkus writes:
> >> I stand by the position that it's way too late in the cycle for
> >> insufficiently-thought-out proposals for major behavioral changes.
> >
> > I don't see how announcing this earlier in the dev cycle would help, at
> >
Bruce Momjian writes:
> Well, since I asked in April of 2009, at the beginning of the cycle, 6
> years after the introduction of the variable, and we still are not doing
> it, then let's stop pretending we will ever do it.
We have made forward progress since that thread (we fixed the plpgsql
pars
Josh Berkus writes:
>> I stand by the position that it's way too late in the cycle for
>> insufficiently-thought-out proposals for major behavioral changes.
> I don't see how announcing this earlier in the dev cycle would help, at
> all.
We would have more than no-time-at-all to test it and fix
Alex Hunsaker wrote:
> After skimming the thread Bruce linked:
> http://archives.postgresql.org/pgsql-hackers/2009-04/msg00512.php
>
> It certainly seems "insufficiently-thought-out". :(
Just as a clarification, while the GUC was *added* in 8.1, it was
read-only with a value of 'off'. I su
Alex Hunsaker wrote:
> On Fri, Jan 29, 2010 at 14:03, Tom Lane wrote:
> > Alex Hunsaker writes:
> >> On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
> > I stand by the position that it's way too late in the cycle for
> > insufficiently-thought-out proposals for major behavioral changes.
>
> Afte
> I stand by the position that it's way too late in the cycle for
> insufficiently-thought-out proposals for major behavioral changes.
I don't see how announcing this earlier in the dev cycle would help, at
all. The people who read -hackers have been using
standards-conforming-strings for years.
On Fri, Jan 29, 2010 at 14:03, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
> I stand by the position that it's way too late in the cycle for
> insufficiently-thought-out proposals for major behavioral changes.
After skimming the thread Bruce linked:
Tom Lane wrote:
> Alex Hunsaker writes:
> > On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
> >> [ still bearing scars from the 8.3 implicit-cast business, which we
> >> didn't think would generate nearly the backlash it did... ]
>
> > Yeah that was my first reaction. But then again we also have
Alex Hunsaker writes:
> On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
>> [ still bearing scars from the 8.3 implicit-cast business, which we
>> didn't think would generate nearly the backlash it did... ]
> Yeah that was my first reaction. But then again we also have a guc
> they can change bac
Joshua D. Drake wrote:
> (4) The 8.3 issue wasn't nearly as bad as Tom is making it out to be.
> Yes, there was a lot of WTF going on, but only by people that aren't
> paying attention anyway and the work to fix it was pretty nominal.
The big mistake we made in 8.3 is not having those compatibilit
Tom Lane wrote:
> I wrote:
> > Bruce Momjian writes:
> >> With the release of Postgres 9.0, should we consider changing the
> >> default for 'standard_conforming_strings'?
>
> > I'm inclined to think we're going to have enough problems without that.
>
> BTW, core already had that discussion, but
On Fri, 2010-01-29 at 15:45 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > With the release of Postgres 9.0, should we consider changing the
> > > default for 'standard_conforming_strings'?
> >
> > I'm inclined to think we're going to have enough problems without th
In response to Bruce Momjian :
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > With the release of Postgres 9.0, should we consider changing the
> > > default for 'standard_conforming_strings'?
> >
> > I'm inclined to think we're going to have enough problems without that.
> > Changing that de
On Fri, Jan 29, 2010 at 3:28 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> With the release of Postgres 9.0, should we consider changing the
>> default for 'standard_conforming_strings'?
>
> I'm inclined to think we're going to have enough problems without that.
> Changing that default will brea
On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
> I wrote:
>> Bruce Momjian writes:
>>> With the release of Postgres 9.0, should we consider changing the
>>> default for 'standard_conforming_strings'?
>
>> I'm inclined to think we're going to have enough problems without that.
> [ still bearing s
Tom Lane wrote:
> Bruce Momjian writes:
> > With the release of Postgres 9.0, should we consider changing the
> > default for 'standard_conforming_strings'?
>
> I'm inclined to think we're going to have enough problems without that.
> Changing that default will break, approximately speaking, ever
I wrote:
> Bruce Momjian writes:
>> With the release of Postgres 9.0, should we consider changing the
>> default for 'standard_conforming_strings'?
> I'm inclined to think we're going to have enough problems without that.
BTW, core already had that discussion, but maybe I should repeat it
to try
Bruce Momjian writes:
> With the release of Postgres 9.0, should we consider changing the
> default for 'standard_conforming_strings'?
I'm inclined to think we're going to have enough problems without that.
Changing that default will break, approximately speaking, every single
Postgres client app
On Jan 29, 2010, at 11:51 AM, Bruce Momjian wrote:
> With the release of Postgres 9.0, should we consider changing the
> default for 'standard_conforming_strings'?
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
Bruce Momjian wrote:
> With the release of Postgres 9.0, should we consider changing the
> default for 'standard_conforming_strings'?
If not now, when?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
61 matches
Mail list logo
