Andrew Dunstan <andrew@dunslane.net> writes:
> If we're going to do backwards compatibility for psql then we need to do
> it in a fairly comprehensive way, not bit by bit, because we can
> reasonably say either "we support backwards compatibility" or "we don't
> support backwards compatibility", but we cannot reasonably say "we
> support backwards compatibility just for these commands" - that's way
> too confusing.
Yeah. It would be good to set some parameters before starting: how far
back is reasonable to support? pg_dump goes back to 7.0 but that's now
mostly for historical reasons, ie, 7.0 was the immediately previous
release when we started making it do backwards-compatible dumps. I'm
not sure it's worth the trouble to make psql go that far back. "Back
to 8.0" would be a nice round figure...
> The task is probably non-trivial - just look at pg_dump.
> Might be another good starting hackers project.
If you consulted the back branches of psql source code it wouldn't be
too hard I would think, though surely tedious.
As an aside, I would most certainly NOT use the "switch" coding style
suggested upthread, as that is guaranteed to break completely every time
there's a version bump. Do it the way pg_dump does, with a series of
"if (version >= something)" tests. Then you only have to change a given
piece of code when there's a direct reason to change it.
regards, tom lane