| From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
|---|---|
| To: | Jim Nasby <jim(at)nasby(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] SQL assertions prototype |
| Date: | 2013-12-18 19:42:53 |
| Message-ID: | 1387395773.14410.YahooMailNeo@web162901.mail.bf1.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jim Nasby <jim(at)nasby(dot)net> wrote:
> This is another case where it would be very useful to restrict
> what relations a transaction (or in this case, a substransaction)
> can access. If we had the ability to make that restriction then
> we could force assertions that aren't plain SQL to explicitly
> specify what tables the assert is going to hit, and if the assert
> tries to do something different then we throw an error.
>
> The ability to restrict object access within a transaction would
> also benefit VACUUM and possibly the Changeset stuff.
I'm pretty sure that SSI could also optimize based on that,
although there are probably about 10 other optimizations that would
be bigger gains before getting to that.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-12-18 19:45:06 | Re: [PATCH] SQL assertions prototype |
| Previous Message | Alvaro Herrera | 2013-12-18 19:39:58 | Re: [PATCH] SQL assertions prototype |