Re: tripping an assert in 8.1.6 (more info) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tripping an assert in 8.1.6 (more info)
Date
Msg-id 5503.1169592664@sss.pgh.pa.us
Whole thread Raw
In response to Re: tripping an assert in 8.1.6 (more info)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: tripping an assert in 8.1.6 (more info)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> I'm tempted to suggest that we just remove the Assert on vartypmod in
> the 8.1 branch.  The Assert on vartype is doing as much as is really
> important to check, and I don't want to disable the trivial_subqueryscan
> optimization, which seems the only other low-risk fix.

After further thought I've developed a modified version of Brian's case
that crashes 8.2 and HEAD but not 8.1 --- it turns the situation around
by having the view fall back to typmod -1.  So what I'm now thinking
is that the real problem is that an Append path generates its Vars by
copying the first input, and in these sorts of situations that might not
produce the correct typmod.  Back to the drawing board ...
        regards, tom lane


CREATE TABLE foo
(x_data varchar(32),row_date date
);

CREATE TABLE bar
(x_data varchar(36),row_date date
);

CREATE OR REPLACE VIEW bazz AS
SELECT       ('bar: ' || bar.row_date) :: TEXT AS action,       bar.x_data AS more_data,row_date
FROM       bar
UNION ALL
SELECT       ('foo: ' || foo.row_date) :: TEXT AS action,       foo.x_data AS more_data,row_date
FROM       foo
;

SELECT action, more_data FROM bazz;


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: About PostgreSQL certification
Next
From: Mark Kirkwood
Date:
Subject: Re: About PostgreSQL certification