2016-02-08 13:22 GMT+01:00 Marko Tiikkaja <ma...@joh.to>:

> On 08/02/16 13:17, Pavel Stehule wrote:
>> 2016-02-08 13:03 GMT+01:00 Marko Tiikkaja <ma...@joh.to>:
>>> How does this function know which schema variables are visible?
>> function see all schema variables from same schema as function's schema
> 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, and cannot be in conflict with PLpgSQL variable, because any
plpgsql variable can overwrite it. But prefix can be used.


CREATE OR REPLACE FUNCTION increment_counter()
RETURNS void AS $$
  test_schema.local_counter := test_schema.local_counter + 1;
$$ LANGUAGE plpgsql;

I would not to allow dependency on SEARCH_PATH, because then the change of
SEARCH_PATH can require replanning and possibly can change result type. So
using SEARCH PATH is way to hell. More I would to "protect" content of
variable - and the schema scope can work like good guard. If you need
public visible variables, then you can use trivial functions, that will do
it - and publish content by functions.



> .m

Reply via email to