Re: Review: Fix snapshot taking inconsistencies - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Review: Fix snapshot taking inconsistencies
Date
Msg-id 649.1286202686@sss.pgh.pa.us
Whole thread Raw
In response to Re: Review: Fix snapshot taking inconsistencies  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Responses Re: Review: Fix snapshot taking inconsistencies  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Re: Review: Fix snapshot taking inconsistencies  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi> writes:
> On 2010-10-04 6:19 AM, Steve Singer wrote:
>> Is there any third party code in particular that your thinking of?  I don't
>> see anything that says pg_parse_and_rewrite is part of a stable server
>> side API (in contrast to SPI or something an third party index access method
>> or custom data-type would call).

> 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.

The important thing in such cases is to not break third-party code
*silently*.  You want to make sure that they'll get a compilation
error if they haven't adjusted their code.  Change the parameter
list or invent a new name for the function.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: is sync rep stalled?
Next
From: Hakan Kocaman
Date:
Subject: MIT benchmarks pgsql multicore (up to 48)performance