Re: [PATCH] SQL assertions prototype - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [PATCH] SQL assertions prototype
Date
Msg-id 52B21043.6090202@dunslane.net
Whole thread Raw
In response to Re: [PATCH] SQL assertions prototype  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On 12/18/2013 04:09 PM, Heikki Linnakangas wrote:
> On 12/18/2013 11:04 PM, Andrew Dunstan wrote:
>>
>> On 12/18/2013 02:45 PM, Andres Freund wrote:
>>> On 2013-12-18 16:39:58 -0300, Alvaro Herrera wrote:
>>>> Andres Freund wrote:
>>>>> It would only force serialization for transactions that modify tables
>>>>> covered by the assert, that doesn't seem to bad. Anything covered 
>>>>> by an
>>>>> assert shoulnd't be modified frequently, otherwise you'll run into
>>>>> major
>>>>> performance problems.
>>>> Well, as presented there is no way (for the system) to tell which 
>>>> tables
>>>> are covered by an assertion, is there?  That's my point.
>>> Well, the patch's syntax seems to only allow to directly specify a SQL
>>> query to check - we could iterate over the querytree to gather all
>>> related tables and reject any function we do not understand.
>>
>> Umm, that's really a major limitation in utility.
>
> The query can be "SELECT is_my_assertion_true()", and the function can 
> do anything.
>
>

OK, but isn't that what Andres is suggesting we reject?

cheers

andrew




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: array_length(anyarray)
Next
From: Josh Berkus
Date:
Subject: Re: [PATCH] SQL assertions prototype