Refactoring psql for backward-compatibility
От
David Fetter
Тема
Refactoring psql for backward-compatibility
Дата
Msg-id
20051214095256.GA28965@fetter.org
Список
Дерево обсуждения
Refactoring psql for backward-compatibility David Fetter <david@fetter.org>
Re: Refactoring psql for backward-compatibility Hannu Krosing <hannu@skype.net>
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 Alvaro Herrera <alvherre@commandprompt.com>
Re: Refactoring psql for backward-compatibility Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Refactoring psql for backward-compatibility David Fetter <david@fetter.org>
Re: Refactoring psql for backward-compatibility Christopher Kings-Lynne <chriskl@familyhealth.com.au>
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
Дата: