UPDATED Patch for adding DATACUBE operator
sumit
Can someone inform us of the developments regarding our code on
DATACUBE? We would like to know if there are somethings which we might
have overlooked. If possible, can we also know if we can expect it to be
added to this release?
Sumit
Srikanth
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
Tom Lane
> Can someone inform us of the developments regarding our code on
> DATACUBE? We would like to know if there are somethings which we might
> have overlooked. If possible, can we also know if we can expect it to be
> added to this release?
I'm sorry, but that patch will never be accepted in anything close to
its present form. You've taken what is fundamentally a grouping
construct and implemented it in an altogether inappropriate place,
namely the top level of the system. You mention that it doesn't work in
subselects, but there are a bunch of other ways that it fails to work,
too. (For example, SQL99 expects that a CUBE list can be used in
combination with other grouping columns.) If the patch had a growth
path that would eventually address such concerns, we would consider it
as a partial implementation, but as far as I can see the only growth
path is to throw it out and start over. We've accepted patches in the
past that did things at the wrong level (INTERSECT/EXCEPT comes to mind),
and have learned painfully that we don't want to do that again.
An implementation that would actually meet the spec would probably
involve extending the code in executor/nodeGroup.c and related files,
and perhaps tweaking the planner if CUBE requires any changes in the
structure of the plan tree (offhand I can't tell if it does or not).
You'd also need to extend the parsetree representation of GROUP BY
lists so that a CUBE operation could be distinguished from ordinary
grouping.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majo...@postgresql.org)
sumit
We plan to reimplement the CUBE operator in PostgreSQL after
errors in our approach were pointed out to us during the submission of our
patch last time. This time, we would like to follow the approach given
below. Kindly give your opinion/comments.
As opposed to our earlier approach in which we implemented the
operator at the top level, this time we plan to create a separate
parsetree for the CUBE query so that this can be taken in as another
parseitem on the outer tree in the case of nested queries. This would in
turn, solve the problems faced earlier regarding non-functioning in the
case of VIEWS, UNION et al.
Please send in your suggestions regarding this approach so that we
can start work on it.
Srikanth
Sumit
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?