Re: plpgsql.consistent_into

>> I am thinking so GUC and plpgsql option can live together. If you like to
>> accent a some behave, then you can use a plpgsql option. On second hand, I
>> would to use a some functionality, that is safe, but I don't would to dirty
>> source code by using repeated options. But I have to check (and calculate
>> with risk) a GUC settings.
>>
>> One idea: required GUC? Can be nice a possibility to ensure some GUC
>> setting, and restore ensure these values or raises warning.
>>
>> Back to main topic. Required and described feature doesn't change a
>> behave of INTO clause. I can enable or disable this functionality and well
>> written code should to work without change (and problems). When check is
>> disabled, then execution is just less safe. So in this case, a impact of
>> GUC is significantly less than by you described issues. Does know anybody a
>> use case where this check should be disabled?
>>
>> Probably we have a different experience about GUC. I had a problem with
>> standard_conforming_strings and bytea format some years ago. Now I prepare
>> document about required setting. But I can see (from my experience from
>> Czech area) more often problems related to effective_cache_size or
>> from_collapse_limit and similar GUC. These parameters are behind knowledge
>> (and visibility) typical user.
>>
>
> ISTM that in this case, it should be safe to make the new default behavior
> STRICT; if you forget to set the GUC to disable than you'll get an error
> that points directly at the problem, at which point you'll go "Oh, yeah...
> I forgot to set X..."
>
>
I disagree - STRICT can be too restrictive - and a combination SELECT INTO
and IF FOUND can be significantly faster - our exception handling is not
cheap.

Regards

Pavel

> Outside of the GUC, I believe the default should definitely be STRICT. If
> your app is relying on non-strict then you need to be made aware of that.
> We should be able to provide a DO block that will change this setting for
> every function you've got if someone isn't happy with STRICT mode.
> --
> Jim C. Nasby, Data Architect jim(at)nasby(dot)net
> 512.569.9461 (cell) http://jim.nasby.net
>