Tatsuo Ishii wrote:
>> Since I didn't hear anything about "API into the Parser / Parser as an
>> independent module", I just wrote my own summary of what I think the
>> idea was there is and am moving on. I'll try to track down more info at
>> PG East next month when I run into some of the people I think care about
>> this.
>>
>
> I have took a look at your description. That is totally different from
> what I thought. Statement replication and/or load balancing middle
> ware need to know SQL statement is SELECT or others. If it is a (read
> only) SELECT, it can be routed to standby node of Streaming
> replication clusters for example. For this purpose, such a middle ware
> ought to be able to parse SQL. If PostgreSQL provide its raw parser as
> a C library, it will be very usefull for such middle ware since they
> do not need to re-implement their own SQL parser (as pgpool-II already
> did).
>
>
I never claimed I really understand what entry was alluding to and just
made the first wild guess that came to mind. I'll be happy to replace
it with the alternate explanation you suggested for what it was intended
to address. The part I still don't see is how these two comments in
that section fit into what you're describing here:
* statement based replication need to replay certain constructs with
CONSTANT values you provide
* Figure out which you need to replace... quite difficult
Those are the parts I was basing my guess as to the intended application
here on. If this is just intended to improve relaying SELECT statements
over to another node, why would you need to replace anything with
constants or other values?
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us