On 12/19/2011 11:12 AM, Robert Haas wrote:
But before we get bogged down in the data representation, I think we
need to make a more fundamental decision: to what extent are we OK
with exporting the parse tree at all, in any form?  Tom is arguing
that we shouldn't, and I see his point: the recent DROP command rework
would have broken everybody's command triggers if we had adopted this
proposal, and that would be a real shame, because I don't particularly
like the idea that we can't continue to improve the code and refactor
things because someone out there might be depending on an older and
less well-considered behavior.

Any interface here would need to be in the same sense Linux uses the term: subject to change in every major version, and maybe even in a minor one if that's the best way to solve a higher priority issue. An example we've been consuming that comes to mind is the "API" for keeping processes from being killed by the OOM killer. It's far from stable: http://archives.postgresql.org/message-id/4ce5e437.7080...@2ndquadrant.com but it's still possible for users of it to keep up with new releases, and when feasible some work toward backward compatibility is done (but not always)

As a tool author, I would expect anything working at the level where the data needed is only available from the parse tree would need to be re-tested against each new version, and then have version specific changes as needed. Setting the expectations bar any higher for consumers of that interface would be unrealistic. The minority of people who'd like to use this feature shouldn't want to see PostgreSQL development hamstrung for the majority either, and the standards for breakage here should be clear from the beginning--unlike those for, say, GUC changes between releases.

--
Greg Smith   2ndQuadrant US    g...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to