| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: proposal: session server side variables |
| Date: | 2017-02-03 10:18:56 |
| Message-ID: | alpine.DEB.2.20.1702031039370.4856@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> We can implement XA support for variables, ale I don't think so default
> should be XA.
I was answering your question, which is what you can do about the
feedback: take the one hard/strong point into account in your proposal.
You do not want to do that. Too bad.
The argument that you keep on repeating about "other software do it like
that so it is the good way" do not work because these software (Oracle,
DB2, ...) have features unavailable to postgres which mitigate the issue
I'm raising, and there is no such mitigation in postgres.
Note that you can proceed and simply ignore my negative opinion, which
will stay negative till these "secure" variables are transactional by
default, or till nested/autonomous transactions are provided by postgres.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2017-02-03 10:19:16 | Re: proposal: session server side variables |
| Previous Message | Antonin Houska | 2017-02-03 10:04:08 | Re: asynchronous execution |