>> 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.



> --
> 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

Reply via email to