Re: proposal: schema PL session variables

2016-02-09 15:32 GMT+01:00 Marko Tiikkaja <marko(at)joh(dot)to>:

> On 08/02/16 14:16, Pavel Stehule wrote:
>
>> 2016-02-08 13:53 GMT+01:00 Marko Tiikkaja <marko(at)joh(dot)to>:
>>
>>>
>>> Yeah, and that's exactly what I don't want, because that means that
>>> CREATE
>>> SCHEMA VARIABLE suddenly breaks existing code.
>>>
>>>
>> theoretically yes, but this conflict can be 100% detected - so no quiet
>> bug
>> is possible, and plpgsql_check can find this issue well. If you don't use
>> schema variable, then your code will be correct. You have to explicitly
>> create the variable, and if there will be any problem, then the problem
>> will be only in PL functions in one schema. And you can identify it by
>> statical analyse.
>>
>
> I'm sorry, but I think you've got your priorities completely backwards.
> You're saying that it's OK to add a footgun because blown-off pieces of
> feet can be found by using a third party static analyzer barely anyone
> uses. And at best, that footgun is only a very minor convenience (though
> I'd argue that omitting it actually hurts readability).
>

I don't block the integration plpgsql_check to upstream. I spent hundreds
hours for it.

Can we look on this problem with different side? What I can do it for safe
using proposed schema variables.

The possible ways:

1. requirement prefix like : or @. I don't prefer it because a) hard to
find a agreement - Oracle fans like ":", MSSQL like @, other maybe $, b)
with any currently unsupported syntax I have to fix SQL lexer, parser

2. requirement to use qualified name everywhere - it can works, but I don't
prefer it, because sometimes can be unfunny to write long qualified
identifiers. There are not aliases on schema in PLpgSQL. Possible solved by
variable aliases. But it requires alias.

3. plpgsql GUC where schema variables are: a) disabled, b) enabled, c) only
qualified names are allowed - it is similar to #variable_conflict option

I prefer @3 with "c" as default, but I can live with @2, and dislike @1 due
mentioned reasons.

Can you be satisfied by any mentioned variant?

Regards

Pavel

>
> That makes absolutely no sense to me at all.
>
>
> .m
>