On Mon, Nov 7, 2011 at 11:25 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> But I can't help feeling that as we continue to add more features,
> we've eventually going to end up with our backs to the wall. Not sure
> what to do about that, but...
Seriously, parts of psql are starting to become a real mess.
[tangentially related rant]
I cringe whenever I have to go digging around in describe.c.
describeOneTableDetails() is what, 1100+ lines?! Doubtless, some
refactoring of that function would help. But the
backwards-compatibility burden isn't helping the situation. The first
conditional block based on pset.sversion in that function contains:
... else if (pset.sversion >= 80000) {
[some query against pg_catalog.pg_class] } else { printfPQExpBuffer(&buf, "SELECT
relchecks,relkind, relhasindex, relhasrules, " "reltriggers <> 0, relhasoids, "
"'', ''\n" "FROM pg_catalog.pg_class WHERE oid = '%s';", oid);
}
We're essentially pretending that we support all server versions with
this code, instead of erroring out on some definite old version and
admitting "sorry, can't do it". The latter query would really break on
a 7.1 [*] or earlier server (thanks to "relhasoids"). Other pieces of
the same function would fail on 7.2 or earlier, e.g. due to querying
pg_depend or pg_namespace. Other code will fail on 7.3 or earlier,
e.g. due to querying pg_user.
I think we should draw a line somewhere about just how far back psql
must support, and don't worry about having crufty "maybe it works but
who knows exactly how far back" code for further support than that. I
think 8.0 would be a very generous backwards compatibility target.
Josh
--
[*] I based these claims about how far back the code would actually
work based on perusing old catalog doc pages, like:
http://www.postgresql.org/docs/7.3/static/catalogs.html
It's possible some of the old doc pages are incorrect, but I think my
point still stands.
