Tom,
Tom Lane wrote:
In fact, parsing this SQL dialect would just be the first step, as the
annotations within the query induce an ordering of the result set.
So I need this extra information in the query to accomplish the
subsequent task of sorting the result set in a certain way before the
result is returned to the client. I'll have to use some hand crafted
internal data structures to do this sorting.
Seems like you could save a large amount of work if you can express what
you want to do as ORDER BY a user-defined operator.
thanks for your reply.
I'll take a look at them. Unfortunately, I'm only the poor chap that has
to implement a proof of concept for the solution that others worked out.
If you insist on bolting it on as new SQL syntax, changing the parser
will be only the tip of the iceberg --- you'll likely need planner and
executor changes as well. You could get a rough idea of what's involved
in adding a new kind of query clause by looking at the last patch that
did so:
So, part of the fun will be digging in PostgreSQL and searching for the
easiest way to implement our solution.
> http://archives.postgresql.org/pgsql-committers/2006-08/msg00251.php
Seems like I should prepare for a long journey. So, while we're at it:
Where can I find the Definitive Design Guide with valuable in-depth
information for pgsql hackers? Is there any information apart from the
official manual
http://www.postgresql.org/docs/8.0/interactive/server-programming.html
and the source itself that you can recommend? I'm especially interested
in how the typical implementation scheme for RDBMS found in textbooks
maps to pgsql. You see, I'm looking for the K&R for pgsql.
Regards,
Matthias
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
