Re: Assertion failure on UNLOGGED VIEW and SEQUENCE
От | Robert Haas |
---|---|
Тема | Re: Assertion failure on UNLOGGED VIEW and SEQUENCE |
Дата | |
Msg-id | AANLkTimO-RxPBipBfQnLtnEW66Jyez1oz=APiBqvNGqA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assertion failure on UNLOGGED VIEW and SEQUENCE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Assertion failure on UNLOGGED VIEW and SEQUENCE
|
Список | pgsql-hackers |
On Fri, Feb 18, 2011 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > If by the first option you mean causing the failure report to be "syntax > error" rather than anything more specific, then I agree that option > sucks. I'd actually vote for putting the error test somewhere in > statement execution code, well downstream of gram.y. The parser's job > is to produce a parse tree, not to encapsulate knowledge about which > combinations of options are supported. OK. Proposed patch attached. It looks to me like an unlogged view is inherently nonsensical, whereas an unlogged sequence is sensible but we don't implement it (and may never implement it, absent some evidence that the overhead of WAL logging sequence changes is worth getting excited about), so I wrote the error messages to reflect that distinction. I also added a couple of matching regression tests, and documented that UNLOGGED works with SELECT INTO. I put the check for views in DefineView adjacent to the other check that already cares about relpersistence, and I put the one in DefineSequence to match, at the top for lack of any compelling theory of where it ought to go. I looked at stuffing it all the way down into DefineRelation but that looks like it would require some other rejiggering of existing logic and assertions, which seems pointless and potentially prone to breaking things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: