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

From Hannu Krosing
Subject Re: Refactoring psql for backward-compatibility
Date
Msg-id 1134603905.3759.13.camel@localhost.localdomain
Whole thread Raw
In response to Refactoring psql for backward-compatibility  (David Fetter <david@fetter.org>)
List pgsql-hackers
Ühel kenal päeval, K, 2005-12-14 kell 01:52, kirjutas David Fetter:
> 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...?

It would be much nicer if we could just add pg_psql schema with a view
for each argumentless command and a C/plpgsql/sql function for each
command taking arguments. 

And one 'main' view, which lists all shlash commands to instrument the
psql at connect or when doing the actual \x

it is a waste of programmer resources, that eachtool doing introspection
has to reimplement them.

and this would also allow sute admins to add new commands to their
specific databases , perhaps "\slony tables" for listing all tables
tohether with their slony status (subscriber, master, not replicated)
and other status info 

------------
Hannu




pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: 7.3 failure on platypus
Next
From: Tatsuo Ishii
Date:
Subject: Extended queries