Re: [HACKERS] Adding support for Default partition in partitioning - Mailing list pgsql-hackers

On Tue, Apr 25, 2017 at 1:20 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
>> I suspect it could be done as of now, but I'm a little worried that it
>> might create grammar conflicts in the future as we extend the syntax
>> further.  If we use CREATE TABLE ... PARTITION OF .. DEFAULT, then the
>> word DEFAULT appears in the same position where we'd normally have FOR
>> VALUES, and so the parser will definitely be able to figure out what's
>> going on.  When it gets to that position, it will see FOR or it will
>> see DEFAULT, and all is clear.  OTOH, if we use CREATE TABLE ...
>> DEFAULT PARTITION OF ..., then we have action at a distance: whether
>> or not the word DEFAULT is present before PARTITION affects which
>> tokens are legal after the parent table name.
>
> As long as we handle this at the transformation stage, it shouldn't be
> a problem. The grammar would be something like
> CREATE TABLE ... optDefault PARTITION OF ...
>
> If user specifies DEFAULT PARTITION OF t1 FOR VALUES ..., parser will
> allow that but in transformation stage, we will detect it and throw an
> error "DEFAULT partitions can not contains partition bound clause" or
> something like that. Also, documentation would say that DEFAULT and
> partition bound specification are not allowed together.

That's not what I'm concerned about.  I'm concerned about future
syntax additions resulting in difficult-to-resolve grammar conflicts.
For an example what of what I mean, consider this example:

http://postgr.es/m/9253.1295031520@sss.pgh.pa.us

The whole thread is worth a read.  In brief, I wanted to add syntax
like LOCK VIEW xyz, and it wasn't possible to do that without breaking
backward compatibility.  In a nutshell, the problem with making that
syntax work was that LOCK VIEW NOWAIT would then potentially mean
either lock a table called VIEW with the NOWAIT option, or else it
might mean lock a view called NOWAIT.  If the NOWAIT key word were not
allowed at the end or if the TABLE keyword were mandatory, then it
would be possible to make it work, but because we already decided both
to make the TABLE keyword optional and allow an optional NOWAIT
keyword at the end, the syntax couldn't be further extended in the way
that I wanted to extend it without confusing the parser.  The problem
was basically unfixable without breaking backward compatibility, and
we gave up.  I don't want to make the same mistake with the default
partition syntax that we made with the LOCK TABLE syntax.

Aside from unfixable grammar conflicts, there's another way that this
kind of syntax can become problematic, which is when you end up with
multiple optional keywords in the same part of the syntax.  For an
example of that, see
http://postgr.es/m/603c8f070905231747j2e099c23hef8eafbf26682e5f@mail.gmail.com
- that discusses the problems with EXPLAIN; we later ran into the same
problem with VACUUM.  Users can't remember whether they are supposed
to type VACUUM FULL VERBOSE or VACUUM VERBOSE FULL and trying to
support both creates parser problems and tends to involve adding too
many keywords, so we switched to a new and more extensible syntax for
future options.

Now, you may think that that's never going to happen in this case.
What optional keyword other than DEFAULT could we possibly want to add
just before PARTITION OF?  TBH, I don't know.  I can't think of
anything else we might want to put in that position right now.  But
considering that it's been less than six months since the original
syntax was committed and we've already thought of ONE thing we might
want to put there, it seems hard to rule out the possibility that we
might eventually think of more, and then we will have exactly the same
kind of problem that we've had in the past with other commands.  Let's
head the problem off at the pass and pick a syntax which isn't
vulnerable to that sort of issue.

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