2016-02-08 13:53 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
On 08/02/16 13:41, Pavel Stehule wrote:
2016-02-08 13:22 GMT+01:00 Marko Tiikkaja <marko@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 them by prefixing them with the schema name (or maybe allow search_path to be used).
I hope so there are not new conflicts - schema variable is not directly visible from SQL (in this iteration) - they are visible only from functions - and the behave is same like global plpgsql variable. So schema variable can be in conflict with SQL identifier only exactly identically as plpgsql variable
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.
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 necessary.
explicit safe prefixing can be used by developers "_" local variable, "__" schema 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.