Re: proposal: schema PL session variables
| От | Pavel Stehule |
|---|---|
| Тема | Re: proposal: schema PL session variables |
| Дата | |
| Msg-id | CAFj8pRDv85B_3J26cXVhqsGsYAw6yACHAGiHgRZ5skcpj34zwQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: schema PL session variables (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
| Ответы |
Re: proposal: schema PL session variables
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: