Marko Tiikkaja <marko.tiikk...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
