Re: BUG #8606: Materialized View WITH NO DATA bug - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #8606: Materialized View WITH NO DATA bug
Date
Msg-id 21660.1385241351@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #8606: Materialized View WITH NO DATA bug  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-bugs
Kevin Grittner <kgrittn@ymail.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> But having said that, it seems that this complaint implies that
>> CREATE MATERIALIZED VIEW ... WITH NO DATA still runs the query
>> through a planning cycle.  Why is that?  I can't immediately see
>> any benefit to doing so.

> Well, to be honest, it's because CREATE TABLE AS ... WITH NO DATA
> does so, and I figured that if it was needed there I didn't see why
> CREATE MATERIALIZED VIEW AS ... WITH NO DATA would be any
> different.  I'm shameless in copying what seems to be working.

I looked at that a bit.  The reason we have to plan, in the current code,
is that we create the target table using column type info from the output
tupdesc supplied by the executor; so we have to have a plan to fire up the
executor on, even if we aren't going to fetch any data from the plan.

It's conceivable that we could extract result type info directly from
the original query (a la DefineVirtualRelation), but it'd be a significant
amount of work and it would mean that the WITH DATA and WITH NO DATA code
paths would be almost completely disjoint.  Worse, we'd still need
something pretty close to what we've got now to handle the CREATE TABLE
AS ... EXECUTE case, making that probably a third totally separate path.

So I'm thinking it's not worth the trouble to avoid a planning cycle
here.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Server may segfault when using slices on int2vector
Next
From: Michael Meskes
Date:
Subject: Re: BUG #8611: ECPG: unclosed comment "/*"