Hi Amit,

thanks for working on this. Seems the last version of the patch was submitted more than 2 months ago and I believe large parts of it will get reworked based on the extensive discussion on this list, so I haven't looked at the code at all.

I'd like to comment on the one thing and that's the syntax. It seems to me we're really trying to reinvent the wheel and come up with our own version of the syntax. Is there a particular reason why not to look at the syntax of the other databases and adapt as much of the existing syntax as possible?

I think that's for a few reasons - firstly it makes the life much easier for the DBAs and users who are either migrating to PostgreSQL or have to manage a mix of databases. Secondly, it serves as a valuable source of engineering info, preventing the "I haven't thought of this use case" problem.

An example of this is the proposed syntax for adding a partition

  CREATE TABLE measurement_fail
  PARTITION OF measurement
  FOR VALUES START ('2006-02-15') END ('2006-03-01');

which seems a bit awkward as both the databases I'm familiar with (Oracle and Sybase) use ALTER TABLE to do this

  ALTER TABLE measurement
    ADD PARTITION measurement_fail VALUES LESS THAN ( ... )

And so on for the other commands.

That being said, I entirely agree with Simon (and others) that getting the planner part work is the crucial part of the patch. But I also think that a proper abstraction (thanks to good syntax) may be a valuable hint how to define the catalogs and such.


Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to