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.7080902@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 greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
