SQL access to variables needs a) change in SQL parser (with difficult discussion about syntax) or b) generic get/set functions. @b can be used in other PL in first iteration.
I afraid to open pandora box and I would to hold the scope of this patch too small what is possible - to be possible implement it in one release cycle.
I agree about implementation. I disagree about design.
Right now it appears zero thought has gone into what SQL level access would eventually look like. Which means there's a high risk that something gets implemented now that we regret later.
So I think adding something like this needs to at least address *how* SQL level access would work, *when* it's eventually implemented.
I understand - and I agree.
small note: Private variables should not be executed from any SQL, because SQL has not directly related schema. It can be executed only from SQL embedded in some object with attached schema - PL functions, views, constraints, .. So for this use case, the important information is info about a container. We have to hold info about related schema in planner/executor context.
Regards
Pavel
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com