Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> However, I wonder if the oid field should be also preserved at same
>> place, not inside a specific trigger function.
>
> Possibly. I wasn't planning to mess with it now; but if you've fixed
> the other problems with assigning to a sys
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> However, I wonder if the oid field should be also preserved at same
> place, not inside a specific trigger function.
Possibly. I wasn't planning to mess with it now; but if you've fixed
the other problems with assigning to a system column then maybe we
s
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> Andrew Dunstan wrote:
>>> Wouldn't this omit comparing the null bitmap?
>
>> Oops, I added the comparison of null bitmap here.
>
> That's really, really ugly code. Why would it be necessary anyway?
> Shouldn't the security tag be expe
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Wouldn't this omit comparing the null bitmap?
> Oops, I added the comparison of null bitmap here.
That's really, really ugly code. Why would it be necessary anyway?
Shouldn't the security tag be expected to match? I suppose tha
Andrew Dunstan wrote:
KaiGai Kohei wrote:
*** 80,88
HeapTupleHeaderGetNatts(oldheader)) &&
((newheader->t_infomask & ~HEAP_XACT_MASK) ==
(oldheader->t_infomask & ~HEAP_XACT_MASK)) &&
! memcmp(((char *)newheader) + offsetof(HeapTupleHeaderData,
t_b
KaiGai Kohei wrote:
*** 80,88
HeapTupleHeaderGetNatts(oldheader)) &&
((newheader->t_infomask & ~HEAP_XACT_MASK) ==
(oldheader->t_infomask & ~HEAP_XACT_MASK)) &&
! memcmp(((char *)newheader) + offsetof(HeapTupleHeaderData,
t_bits),
!
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
... however, it seems reasonable to assume that the *new* tuple is just
local storage. Why don't you just poke the old tuple's OID into the
new
one before comparing?
OK, that
Tom Lane wrote:
I wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
OK, that will be easy enough. I assume I should still put InvalidOid
back again afterwards, in case someone downstream relies on it.
Can't imagine what ...
Actually ... what *could* change in the f
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
... however, it seems reasonable to assume that the *new* tuple is just
local storage. Why don't you just poke the old tuple's OID into the new
one before comparing?
OK, that will be easy enough. I
I wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> OK, that will be easy enough. I assume I should still put InvalidOid
>> back again afterwards, in case someone downstream relies on it.
> Can't imagine what ...
Actually ... what *could* change in the future is that we might support
UPDATE
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... however, it seems reasonable to assume that the *new* tuple is just
>> local storage. Why don't you just poke the old tuple's OID into the new
>> one before comparing?
> OK, that will be easy enough. I assume I should still put I
Tom Lane wrote:
I wrote:
This method is utterly, utterly unacceptable; you're probably trashing
the contents of a disk buffer there.
... however, it seems reasonable to assume that the *new* tuple is just
local storage. Why don't you just poke the old tuple's OID into the new
one be
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The attached patch sets the OID to InvalidOid for the duration of the
memcmp if the HEAP_HASOID flag is set, and restores it afterwards.
This method is utterly, utterly unacceptable; you're probably trashing
the contents of a
I wrote:
> This method is utterly, utterly unacceptable; you're probably trashing
> the contents of a disk buffer there.
... however, it seems reasonable to assume that the *new* tuple is just
local storage. Why don't you just poke the old tuple's OID into the new
one before comparing?
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The attached patch sets the OID to InvalidOid for the duration of the
> memcmp if the HEAP_HASOID flag is set, and restores it afterwards.
This method is utterly, utterly unacceptable; you're probably trashing
the contents of a disk buffer there. Even
Andrew Dunstan wrote:
> KaiGai Kohei wrote:
>
>> Hi,
>>
>> The suppress_redundant_updates_trigger() works incorrectly
>> on the table defined with "WITH_OIDS" option.
>>
>>
>>
>
> Good catch!
>
> I think ideally we'd just adjust the comparison to avoid the system
> attributes.
>
> I'll
KaiGai Kohei wrote:
> Hi,
>
> The suppress_redundant_updates_trigger() works incorrectly
> on the table defined with "WITH_OIDS" option.
>
> --
> (*) The latest 8.4devel tree without SE-PostgreSQL patch
>
> postgres=# CREATE TABLE min_updates_test (
>f1 text,
>
Hi,
The suppress_redundant_updates_trigger() works incorrectly
on the table defined with "WITH_OIDS" option.
--
(*) The latest 8.4devel tree without SE-PostgreSQL patch
postgres=# CREATE TABLE min_updates_test (
f1 text,
f2 int,
f3 int) with o
18 matches
Mail list logo
