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
