Thomas Munro writes:
> On Wed, Jan 29, 2020 at 4:05 AM Tom Lane wrote:
>> There is absolutely no question that the original coding is illegal
>> per spec, and it isn't even a particularly useful shorthand; so why
>> can't we get even a warning about it?
> $ cc -c -Wpedantic test.c
> test.c:2:12:
On Wed, Jan 29, 2020 at 4:05 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Tue, Jan 28, 2020 at 6:59 PM Tom Lane wrote:
> >> anole's not terribly pleased with this:
> >> "heapam.c", line 9137: error #2118: a void function may not return a value
> >> return CheckForSerializableConflictOut(rela
Thomas Munro writes:
> On Tue, Jan 28, 2020 at 6:59 PM Tom Lane wrote:
>> anole's not terribly pleased with this:
>> "heapam.c", line 9137: error #2118: a void function may not return a value
>> return CheckForSerializableConflictOut(relation, xid, snapshot);
> Thanks. I pushed a fix.
> Wow, HP
On Tue, Jan 28, 2020 at 6:59 PM Tom Lane wrote:
> Thomas Munro writes:
> > Remove dependency on HeapTuple from predicate locking functions.
>
> anole's not terribly pleased with this:
>
> "heapam.c", line 9137: error #2118: a void function may not return a value
> return CheckForSerializa
Thomas Munro writes:
> Remove dependency on HeapTuple from predicate locking functions.
anole's not terribly pleased with this:
"heapam.c", line 9137: error #2118: a void function may not return a value
return CheckForSerializableConflictOut(relation, xid, snapshot);
^
Remove dependency on HeapTuple from predicate locking functions.
The following changes make the predicate locking functions more
generic and suitable for use by future access methods:
- PredicateLockTuple() is renamed to PredicateLockTID(). It takes
ItemPointer and inserting transaction ID ins
