Re: Materialized views WIP patch

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Materialized views WIP patch
Дата
Msg-id CA+Tgmoab4xcBnsVmxj3_hEiKj7FqesX6ET_nOZgvpUgF+_OKEg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Materialized views WIP patch  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Materialized views WIP patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Materialized views WIP patch  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used