On Thu, Nov 10, 2011 at 6:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> As I suggested, many more unexpected failures (e.g. \dnS+) pop up when >> talking to a 7.3 server. It's not a big deal, but it'd be nice if we >> could instead error out with a "sorry, we're too lazy to try to >> support 7.3" on the meta-commands which fail thusly, and make the >> various "else" clauses more explicit about just how far back their >> support really goes. > > Probably not worth the trouble ... how many pre-7.4 servers are still in > the wild, and of those, how many might somebody try to talk to with a > modern psql? > > The more realistic direction of future change, I think, is that we move > up the cutoff version so we can take out some code, rather than add > more. At the moment I'd find it a hard sell to drop support for 8.1 or > later; so maybe there's not enough removable code to make it worth any > effort. But in a few more years it'd be worth doing.
I am 100% on board with dropping support for such old servers whenever feasible, so as to cut down on the cruft in psql -- that's the only reason I cared to go poking at this at all. I would suggest we bump the minimum supported server version for psql up to 8.0 at some point in the not-too-distant future, perhaps even for 9.2. > What *would* be worth doing today, IMO, is ripping out pg_dump's support > for servers older than 7.3 or 7.4; in particular getting rid of its > kluges for server versions without pg_depend info. Yeah, that was another can of worms I had in the back of my mind. I think there's a good case for maintaining longer backwards compatibility in pg_dump vs. psql, to help people upgrade an ancient server to a modern one. But certainly, anything older than 7.3 or 7.4 is pushing the boundaries in terms of being supported. Jsoh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers