Scott Ribe <scott_ribe@xxxxxxxxxxxxxxx> writes:
>> Can you show an actual test case?
> create sequence "DbRowIds";
> create table "PatientRelated" (id int8 not null default
> nextval('"DbRowIds"'));
> create table "Document" (id int8 not null default nextval('"DbRowIds"'));
> create table "PatientDocument" () inherits ("PatientRelated", "Document");
Huh, so it turns out it depends on the exact length of the commands :-(
The code is comparing strings like this:
(gdb) p def->cooked_default
$3 = 0x4015c7a0 "{FUNCEXPR :funcid 1574 :funcresulttype 20 :funcretset false :funcformat 0 :args ({CONST :consttype 2205 :consttypmod -1 :constlen 4 :constbyval true :constisnull false :location 64 :constvalue 4 [ 0 2 108 85 ]}) :location 56}"
(gdb) p this_default
$4 = 0x40125ae0 "{FUNCEXPR :funcid 1574 :funcresulttype 20 :funcretset false :funcformat 0 :args ({CONST :consttype 2205 :consttypmod -1 :constlen 4 :constbyval true :constisnull false :location 59 :constvalue 4 [ 0 2 108 85 ]}) :location 51}"
The location fields shouldn't be considered relevant, but since it's a
plain strcmp() they matter. This used to work as expected, and got
broken by the addition of more syntax location tracking support in 8.4.
I guess we're going to have to rewrite that code to not store the cooked
defaults in string form. If they were node trees then equal() would do
the right thing.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
