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

From Martijn van Oosterhout
Subject Re: Refactoring psql for backward-compatibility
Date
Msg-id 20051214112810.GD16967@svana.org
Whole thread Raw
In response to Refactoring psql for backward-compatibility  (David Fetter <david@fetter.org>)
List pgsql-hackers
On Wed, Dec 14, 2005 at 01:52:56AM -0800, David Fetter wrote:
> 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:

Well, most of the \ commands just end up calling an SQL statement so in
theory it should be possible to seperate those out into seperate files.

sql_7_3.c

char *sql_array[] =
{ [LIST_NAMESPACES] = "SELECT blah";

etc...

And do that for each version. If it's actual code changes required,
perhaps a better approach would be to use function pointers. Create an
array of the possible \ commands and move the functions to a
subdirectory. Then you can do things like:

7.3/table.c

slash_command_func_t func_array_7_3[] =
{ [LIST_NAMESPACES] = list_namespaces_7_3,

If you set current_slashcommands to point to the right array on
startup, then calling the code would be like:

current_slashcommands[cmd]( ... )

The function pointer version may be more flexible and handle more
subtle changes. Including this like "this command does not apply to
this version".

I think your biggest stumbling block will be proving it's not a
maintainence nightmare.

Hope this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Cost-based optimizers
Next
From: Andreas Pflug
Date:
Subject: psql and COPY BINARY