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