v7.3.1 psql against a v7.2.x database ...
gr...@turnstep.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Is this very different from how it's done at present?
Yes. :)
I'd like to play Devil's Advocate a bit on the whole backward-compatible
psql issue. First, I have not seen a lot of clamor for this sort of thing.
Second, psql comes bundled with the project; you cannot build the
postgresql binary without getting the latest and greatest psql installed
as well. So it is not as if this is a standalone app that someone may not
have the latest version of. Having a working version of psql is actually
a prerequisite for releasing a new version of Postgres! Third, the changes
from 7.2 to 7.3 in psql were fairly severe with the addition of schemas,
and don't really lend themselves well to a rewrite to handle previous
versions. I recall someone (Tom?) asked if anyone wanted to step up
to the plate on making something like that some time ago, but nobody did.
Fourth, my custom version is an enhanced 7.2, not a compatible 7.3,
so my existing work would not be too helpful in this case.
I'd support making psql 7.3 and forward be aware of the backend they
are connecting to, and support them being able to work against all 7.3+
servers, but I still fail to see the pressing need for a backward-compatible
version when the correct one is always shipped with the server.
- --
Greg Sabino Mullane gr...@turnstep.com
PGP Key: 0x14964AC8 200301221120
-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html
iD8DBQE+LsVsvJuQZxSWSsgRAlBtAJ95xL+YRgkSwE554ucIFjgAVoaj6ACeOzNs
nyenGFcy4lY2X3vrOJln/HY=
=I0Lw
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
Daniel Kalchev
> I'd support making psql 7.3 and forward be aware of the backend they
> are connecting to, and support them being able to work against all 7.3+
> servers, but I still fail to see the pressing need for a backward-compatible
> version when the correct one is always shipped with the server.
This hits the nail in the head. I was just counting the pros' and cons to
upgrade an large production system from 7.2.3 to 7.3.x.
The trouble is, there is need to access both types of databases, new and old.
Often from the same psql executable.
So psql should definitely be backward compatible!
Daniel
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
Rod Taylor
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Wed, 2003-01-22 at 11:11, gr...@turnstep.com wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
> > Is this very different from how it's done at present?
>=20
> Yes. :)
>=20
> I'd like to play Devil's Advocate a bit on the whole backward-compatible=
=20
> psql issue. First, I have not seen a lot of clamor for this sort of thing=
.=20
> Second, psql comes bundled with the project; you cannot build the=20
> postgresql binary without getting the latest and greatest psql installed=
=20
> as well. So it is not as if this is a standalone app that someone may not=
=20
> have the latest version of. Having a working version of psql is actually=
=20
> a prerequisite for releasing a new version of Postgres! Third, the change=
s=20
> from 7.2 to 7.3 in psql were fairly severe with the addition of schemas,=
=20
> and don't really lend themselves well to a rewrite to handle previous=20
> versions. I recall someone (Tom?) asked if anyone wanted to step up=20
> to the plate on making something like that some time ago, but nobody did.
> Fourth, my custom version is an enhanced 7.2, not a compatible 7.3,=20
> so my existing work would not be too helpful in this case.
>=20
> I'd support making psql 7.3 and forward be aware of the backend they=20
> are connecting to, and support them being able to work against all 7.3+=
=20
> servers, but I still fail to see the pressing need for a backward-compati=
ble=20
> version when the correct one is always shipped with the server.=20
New commands in psql are probably worth the upgrade right there --
especially in the case of 7.3. Protocol changes make it all but
impossible (like what 7.4 is probably going to get).
But, 1/2 the problem can be removed if we stuff the logic into the
backend. This includes moving the queries as well as the list of
available commands.
I say we abuse prepared queries.
Create a table in the database to hold the list of available psql
commands (\dt, \dD, \dS, etc.) along with a preparable query, and the
number of expected arguments:
CREATE TABLE pg_psql_commandset
-- Command as typed in psql (\dt, \dD, \dS, etc)
( command varchar(5)
-- Number of arguments after the command
, nargs smallint
-- The sql whose output will be used directly to display a table
, tablesql text
-- The sql whose output will be displayed as additional lineitems after
-- the table, like foreign keys and primary keys after the table
-- information
, extrasql text
-- A command may be different based on the number of arguments.
, primary key (command, nargs)
);
The entry for \dt would be:
command: \dt
nargs: 0
tablesql: SELECT ....
extrasql: NULL
The entry for '\dt a' would be:
command: \dt
nargs: 1
tablesql: SELECT .. WHERE relname like '^' || ? || '$' ...
extrasql: SELECT key, name, text FROM ....
Execution:
0. Start psql client
1. User types \dt.
2. psql checks to see if '\dt with 0 args' has been prepared (it hasn't)
3. Find info on \dt with 0 args, and pull it out from pg_psql_commandset
4. Since found, prepare \dt with 0 args (assume all args are text for
simplicity). If a command isn't available, tell the user Postgresql 7.x
doesn't support command.
5. Fetch results of the tablesql and extrasql (where not null), and
display to the user.
So long as the structure of the pg_psql_commandset table doesn't change,
all future versions (barring a protocol change) should be able to use
any backend version with an appropriate command set for the backend.
The trickiest part is taking the *.* style args and using them
appropriately, but thats not too difficult.
tablesql and extrasql could (in some cases) simply call system functions
-- but I'd not want to hardcode the function structure as psql would
need to be taught how to deal with varying input types (may end up with
several versions of the function list).
It would be better if prepared statements didn't insist on knowledge of
the datatypes from the client -- but I think they can be discovered from
the context of the variable use instead (Neil?).
Anyway, it's just a thought. psql in 7.4 is free game due to the
anticipated protocol change which will make prior versions
non-functioning anyway.
--=20
Rod Taylor <r...@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
--=-I0bCGXx7evOR5XmK16Eu
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQA+Ltg56DETLow6vwwRAsAOAJ9JpClL27eyJFp0mIaKMvEe/NlzyACfVxIq
50eadLK2rLzPQ25IkLLMG9Q=
=MPgy
-----END PGP SIGNATURE-----
--=-I0bCGXx7evOR5XmK16Eu--
Tom Lane
The scenario where it's valuable involves multiple machines: if you
connect to another machine that is running an older Postgres, it'd be
nice not to have to have a matching psql installed locally. For
example, consider someone who does development work (so has the latest
PG installed on his workstation) but also must admin a production box
with an older PG version installed there. As things currently stand,
he has to keep an extra copy of psql on his workstation to use for
talking to the production server.
But, while I see the value in it, I'm not personally prepared to put in
the work needed to make it happen.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majo...@postgresql.org)