Refactoring psql for backward-compatibility - Mailing list pgsql-hackers

From David Fetter
Subject Refactoring psql for backward-compatibility
Date
Msg-id 20051214095256.GA28965@fetter.org
Whole thread Raw
Responses Re: Refactoring psql for backward-compatibility  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Refactoring psql for backward-compatibility  (Andrew Dunstan <andrew@dunslane.net>)
Re: Refactoring psql for backward-compatibility  (Hannu Krosing <hannu@skype.net>)
Re: Refactoring psql for backward-compatibility  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
List pgsql-hackers
Folks,

I'm trying to come up with a design for \ commands in psql in 8.2.
8.1 broke just about every \ command because they now depend on roles,
which is great for 8.1 or better, but not so good if you're connecting
to DBs <= 8.0.  So, I'm volunteering to code up the next version of
psql, which will be aware of the back-end version, and I'm trying to
figure out what strategy will satisfy the following requirements for \
commands:

1.  Correctness: as in the sense of "works the same way that the
then-current version of psql did."

2.  Maintainability: each new version should be easy to add.

3.  Performance

Neil Conway suggested something like a get_function_list(), which I
presume would be called on connect, and would be version-aware.  Does
this seem like a good idea?  If so, what might an implementation look
like?  I know C isn't all that great for function overloading, so do
we want to keep all the SQL for all previous versions in memory,
or...?

I'd much appeciate tips, specific RTFMs and feedback on this so I can
get cracking on a patch.

Cheers,
D
-- 
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!


pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: ANSI SQL, CASE expression Conformance F262, F263 any info
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Cost-based optimizers