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
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 |