>> 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 j...@nasby.net > 512.569.9461 (cell) http://jim.nasby.net >