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.
regards
--
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:
http://www.postgresql.org/mailpref/pgsql-hackers
