Re: Materialized views WIP patch - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Materialized views WIP patch
Date
Msg-id CA+Tgmoab4xcBnsVmxj3_hEiKj7FqesX6ET_nOZgvpUgF+_OKEg@mail.gmail.com
Whole thread Raw
In response to Re: Materialized views WIP patch  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Materialized views WIP patch
Re: Materialized views WIP patch
List pgsql-hackers
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> it is. http://www.postgresql.org/docs/9.2/static/sql-reset.html
> DISCARD would be better.

Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ... DISCARD.  I think it's a dangerous precedent to
suppose that we're going to start using DISCARD for things that have
nothing to do with the existing meanings of DISCARD.  Number one, I
think it's confusing.  Number two, it's currently possible to
determine whether something is DDL, DML, or other by looking at the
first word of the command.  If we throw that out the window we may
cause performance issues for connection pooling software that tries to
be clever like that.  Mind you, I'm not aware of any connection
pooling software that actually does this today, because I think pgpool
includes a full parser and pgbouncer includes no parser at all, but it
still seems like a possibly-useful trick.  And number three, the
possibility of grammar conflicts with things we might want to do in
the future seems unnecessarily high.  If we use ALTER MATERIALIZED
VIEW ... WHATEVER, we only have to worry about grammar conflicts with
other ALTER MATERIALIZED VIEW commands; if we reuse DISCARD or RESET,
we've got potential conflicts with completely unrelated syntax.  That
consideration alone would be sufficient reason for me to choose to
stick everything under ALTER MATERIALIZED VIEW, no matter how poor a
semantic fit it seems otherwise.  Of course, if we stick with
TRUNCATE, this becomes a non-issue.

All that having been said, I'm not in favor of pushing this patch out
to 9.4 because we can't agree on minor syntax details.  In the absence
of consensus, my feeling is that Kevin should exercise committer's
prerogative and commit this in the way that seems best to him.  If a
clear contrary consensus subsequently emerges, we can always change
it.  It is not as if the particular choice of SQL syntax is hard to
whack around.  Once we release it we're stuck with it, but certainly
between now and beta we can change it whenever we like.  I'd rather
have the core part of the feature committed and tinker with the syntax
than wait longer to land the patch.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Support for REINDEX CONCURRENTLY
Next
From: Dean Rasheed
Date:
Subject: Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used