Re: ERROR: column "id" inherits conflicting default values - Mailing list pgsql-general

From Tom Lane
Subject Re: ERROR: column "id" inherits conflicting default values
Date
Msg-id 17543.1254709854@sss.pgh.pa.us
Whole thread Raw
In response to Re: ERROR: column "id" inherits conflicting default values  (Scott Ribe <scott_ribe@killerbytes.com>)
Responses Re: ERROR: column "id" inherits conflicting default values
List pgsql-general
Scott Ribe <scott_ribe@killerbytes.com> 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 ]})
:location56}" 
(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 ]})
:location51}" 

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

pgsql-general by date:

Previous
From: Guy Rouillier
Date:
Subject: Re: How useful is the money datatype?
Next
From: Christophe Pettus
Date:
Subject: Re: How useful is the money datatype?