From: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Steve Singer <ssinger_pg(at)sympatico(dot)ca>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Review: Fix snapshot taking inconsistencies |
Date: | 2010-10-08 23:07:25 |
Message-ID: | 4CAFA42D.30508@cs.helsinki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2010-10-04 5:31 PM +0300, Tom Lane wrote:
> Marko Tiikkaja<marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> writes:
>> Nope. I think I grepped contrib/ at some point and none of those were
>> using pg_parse_and_rewrite() so this is all just speculation. And yes,
>> it's not really part of any stable API but breaking third party modules
>> needlessly is not something I want to do. However, in this case there
>> is no way to avoid breaking them.
>
> In the particular case at hand here, I rather wonder why SQL functions
> are depending on postgres.c at all. It might be better to just
> duplicate a bit of code to make them independent. pg_parse_and_rewrite
> would then be dead code and could be deleted.
I'm confused. Even if we get rid of pg_parse_and_rewrite, SQL functions
need pg_parse_query and pg_analyze_and_rewrite from postgres.c. You're
not suggesting duplicating the code in those two, are you?
Regards,
Marko Tiikkaja
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-10-09 00:40:03 | Re: Sync Replication with transaction-controlled durability |
Previous Message | Dimitri Fontaine | 2010-10-08 21:59:30 | Re: Sync Replication with transaction-controlled durability |