Re: Strange assertion using VACOPT_FREEZE in vacuum.c - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Strange assertion using VACOPT_FREEZE in vacuum.c
Date
Msg-id 20150228054546.GD29780@tamriel.snowman.net
Whole thread Raw
In response to Re: Strange assertion using VACOPT_FREEZE in vacuum.c  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Strange assertion using VACOPT_FREEZE in vacuum.c  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Michael,

* Michael Paquier (michael.paquier@gmail.com) wrote:
> On Wed, Feb 18, 2015 at 12:09 AM, Robert Haas <robertmhaas@gmail.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

pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: logical column ordering
Next
From: Matt Kelly
Date:
Subject: Re: logical column ordering