From: | Michael Tharp <gxti(at)partiallystapled(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [RFC] nodeToString format and exporting the SQL parser |
Date: | 2010-04-04 20:46:25 |
Message-ID: | 4BB8FAA1.1020507@partiallystapled.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/02/2010 04:16 PM, Tom Lane wrote:
> Generally speaking I'm against
> exposing that data structure to clients, because there will inevitably
> be griping when we change it (as we most certainly will). Your
> complaints boil down to "this is hard to parse from the client side",
> and that already tells me you're doing something that we will refuse
> to support.
Sorry, I got the impression that the node format was intended to be
stable. If it's for internal use only then I don't suppose my
suggestions make much sense.
As for the structure of the parse nodes themselves, changes aren't a big
deal to me. What I'm doing is diffing entire files of DDL, so even if
the node format changes over time the changes in two files parsed using
the same code are still evident. In fact, the ambiguities in parsing
don't really affect this use case much because I don't need exact values
to detect changes.
Markus' link suggests using the parser for a load balancer, which would
require that this all be in library form anyway as the balancer cannot
afford a round trip to the server to parse the query, so maybe I should
focus my efforts there. Making it a separate library would also resolve
the compatibility issues as the library could keep its own structures
regardless of where Postgres goes.
Thanks for the input!
-- m. tharp
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-04-04 21:47:21 | Interesting near-bug in shared-dependency management |
Previous Message | Josh Berkus | 2010-04-04 20:45:37 | Nice hint on table aliasing! |