Re: proposal: schema PL session variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: schema PL session variables
Date
Msg-id CAFj8pRAN0v_63BSTh1etjgvEv80_jroF=oY3riPN+agcdjrmMg@mail.gmail.com
Whole thread Raw
In response to Re: proposal: schema PL session variables  (Marko Tiikkaja <marko@joh.to>)
Responses Re: proposal: schema PL session variables
List pgsql-hackers


2016-02-08 13:22 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
On 08/02/16 13:17, Pavel Stehule wrote:
2016-02-08 13:03 GMT+01:00 Marko Tiikkaja <marko@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.

example:

CREATE OR REPLACE FUNCTION increment_counter()
RETURNS void AS $$
BEGIN
  test_schema.local_counter := test_schema.local_counter + 1;
END;
$$ 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.

Regards

Pavel


 


.m

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: remove wal_level archive
Next
From: Robert Haas
Date:
Subject: Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)