Re: Strange assertion using VACOPT_FREEZE in vacuum.c

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Strange assertion using VACOPT_FREEZE in vacuum.c
Date: 2015-02-28 05:45:46
Message-ID: 20150228054546.GD29780@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael,

* Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> On Wed, Feb 18, 2015 at 12:09 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > I think it's right the way it is. The parser constructs a VacuumStmt
> > for either a VACUUM or an ANALYZE command. That statement is checking
> > that if you are doing an ANALYZE, you can't specify FULL or FREEZE.
> > That makes sense, because there is no ANALYZE FULL or ANALYZE FREEZE
> > command.
>
> Yes, the existing assertion is right. My point is that it is strange
> that we do not check the values of freeze parameters for an ANALYZE
> query, which should be set to -1 all the time. If this is thought as
> not worth checking, I'll drop this patch and my concerns.

I'm trying to wrap my head around the reasoning for this also and not
sure I'm following. In general, I don't think we protect all that hard
against functions being called with tokens that aren't allowed by the
parse. So, basically, this feels like it's not really the right place
for these checks and if there is an existing problem then it's probably
with the grammar... Does that make sense?

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matt Kelly 2015-02-28 06:01:55 Re: logical column ordering
Previous Message Jim Nasby 2015-02-28 05:34:29 Re: logical column ordering