Re: [PATCH] SQL assertions prototype
От | Kevin Grittner |
---|---|
Тема | Re: [PATCH] SQL assertions prototype |
Дата | |
Msg-id | 1387399193.34150.YahooMailNeo@web162903.mail.bf1.yahoo.com обсуждение исходный текст |
Ответ на | Re: [PATCH] SQL assertions prototype (Jim Nasby <jim@nasby.net>) |
Список | pgsql-hackers |
Jim Nasby <jim@nasby.net> wrote: > On 12/18/13, 1:42 PM, Kevin Grittner wrote: >> Jim Nasby <jim@nasby.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. > > Any ideas how hard this would be? If we had a list to check against, I think it would be possible to do this during parse analysis and AcquireRewriteLocks(). (One or the other happens before query rewrite.) The hard part seems to me to be defining a sane way to get the list. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: