Refactoring psql for backward-compatibility

Поиск
Список
Период
Сортировка
От David Fetter
Тема Refactoring psql for backward-compatibility
Дата
Msg-id 20051214095256.GA28965@fetter.org
обсуждение исходный текст
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: "Pavel Stehule"
Дата:
Сообщение: ANSI SQL, CASE expression Conformance F262, F263 any info
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Cost-based optimizers