2016-02-08 13:53 GMT+01:00 Marko Tiikkaja <ma...@joh.to>:
> On 08/02/16 13:41, Pavel Stehule wrote:
>> 2016-02-08 13:22 GMT+01:00 Marko Tiikkaja <ma...@joh.to>:
>>> Personally I find that undesirable. I don't know what oracle does, but
>>> variables being visible without schema-qualifying them can introduce
>>> variable conflicts in PL/PgSQL. I'd prefer if you could only refer to
>>> by prefixing them with the schema name (or maybe allow search_path to be
>> I hope so there are not new conflicts - schema variable is not directly
>> visible from SQL (in this iteration) - they are visible only from
>> - and the behave is same like global plpgsql variable. So schema variable
>> can be in conflict with SQL identifier only exactly identically as plpgsql
> 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
> But prefix can be used.
> Sure, but I don't see the point. Is there a reason not to require such
> variable references to be prefixed with the schema name? Or explicitly
> bring them into scope in the DECLARE section somehow.
we can define any rules, but I see better to be consistent with current
variables design. I don't prefer any mandatory prefixes when it is not
explicit safe prefixing can be used by developers "_" local variable, "__"
I though about DECLARE section too. But more declarations, more copy/paste
or different bugs, and these bugs can be worse detected by static analyse.