Re: Refactoring psql for backward-compatibility

From: Hannu Krosing <hannu(at)skype(dot)net>
To: David Fetter <david(at)fetter(dot)org>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Refactoring psql for backward-compatibility
Date: 2005-12-14 23:45:05
Message-ID: 1134603905.3759.13.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2005-12-15 01:17:17 Extended queries
Previous Message Mark Kirkwood 2005-12-14 23:36:05 Re: 7.3 failure on platypus