Tom,
Actually, what this thread is leading me towards is the idea that almost
nobody really has standard_conforming_strings turned on in production
(except maybe with apps ported from Oracle or someplace else). If they
did, we'd be seeing more complaints about plpgsql not working properly.
So m
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Let me ask this -- If we were to change the plpgsql parser to pay
> > attention to the GUC, it couldn't break anything for any environment
> > which always has the GUC 'off', could it?
>
> Right, because the behavior wouldn't actually change.
>
> I'
"Kevin Grittner" writes:
> Let me ask this -- If we were to change the plpgsql parser to pay
> attention to the GUC, it couldn't break anything for any environment
> which always has the GUC 'off', could it?
Right, because the behavior wouldn't actually change.
I'm starting to lean in the same d
Bruce Momjian writes:
> Brendan Jurd wrote:
>> I agree that there are probably a great many app authors out there who
>> don't realise how very boned they might be if the default GUC gets
>> changed and they haven't prepared their SQL to cope.
> I assume those authors are getting warnings, which
Tom Lane wrote:
> "Kevin Grittner" writes:
>> The aspect of 8.3 behavior that concerns me most is that neither
>> the author of a function, nor anyone using it, can control or
>> predict which way a string literal with a backslash will be
>> interpreted, unless the author explicitly specifies th
Brendan Jurd wrote:
> On Sat, Apr 11, 2009 at 4:40 AM, Kevin Grittner
> wrote:
> > The aspect of 8.3 behavior that concerns me most is that neither the
> > author of a function, nor anyone using it, can control or predict
> > which way a string literal with a backslash will be interpreted,
> > unl
On Sat, Apr 11, 2009 at 4:40 AM, Kevin Grittner
wrote:
> The aspect of 8.3 behavior that concerns me most is that neither the
> author of a function, nor anyone using it, can control or predict
> which way a string literal with a backslash will be interpreted,
> unless the author explicitly specif
"Kevin Grittner" writes:
> The aspect of 8.3 behavior that concerns me most is that neither the
> author of a function, nor anyone using it, can control or predict
> which way a string literal with a backslash will be interpreted,
> unless the author explicitly specifies the SET
> standard_conform
Tom Lane wrote:
>> Can you show one case where having plgpsql parse the function body
>> based on the standard_conforming_strings GUC would break *anything*
>> that now works?
>
> regression=# create function foo() returns int as $$
> regression$# begin
> regression$# raise notice 'foo\'s bar'
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I think you are confusing parsing of the string literal that
>> is the argument of CREATE FUNCTION with the parsing that the plpgsql
>> interpreter does on the function body once it gets it.
> Oh, I'm not confused about that at all. I'm arguing th
Tom Lane wrote:
> I think you are confusing parsing of the string literal that
> is the argument of CREATE FUNCTION with the parsing that the plpgsql
> interpreter does on the function body once it gets it. In
> particular, this example:
>
> create or replace function kjgtest() returns text lan
"Kevin Grittner" writes:
> Unless I'm missing something, plpgsql *already* effectively recognizes
> and respects the standard_conforming_strings GUC *except* as the last
> character of a conforming string literal within the procedure body,
> and then not always. Am I missing something here?
Yes -
"Kevin Grittner" wrote:
> Well, surely the 8.3 behavior is not what we want.
Unless I'm missing something, plpgsql *already* effectively recognizes
and respects the standard_conforming_strings GUC *except* as the last
character of a conforming string literal within the procedure body,
and then
13 matches
Mail list logo
