The keep-annoying-everybody-until-it-really-works caompain
gpg: armor header: Version: GnuPG v1.2.1 (FreeBSD)
gpg: Signature made Mit 22 Jan 2003 18:43:21 CET using DSA key ID 8C3ABF0C
gpg: BAD signature from Rod Taylor (Database Developer) [EMAIL PROTECTED]
On Mit, 2003-01-22 at 18:43, Rod
-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
[EMAIL PROTECTED] said:
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
On Wed, 2003-01-22 at 11:11, [EMAIL PROTECTED] wrote:
-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
Christopher Kings-Lynne wrote:
With ever more larger businesses adopting PostgreSQL, and that leading
on to more places having several versions of PostgreSQL in operation
simultaneously (i.e. development vs production) we're probably going to
need to give psql the ability to handle whichever
[EMAIL PROTECTED] wrote:
snip
I have strongly considered doing this, and even started on the project some
time ago. (I've stopped now). At first I wanted to add 7.3 and 7.4 features
to a 7.2 psql. Then I considered writing a master psql that could handle
any backend. In the end, however, I
With ever more larger businesses adopting PostgreSQL, and that leading
on to more places having several versions of PostgreSQL in operation
simultaneously (i.e. development vs production) we're probably going to
need to give psql the ability to handle whichever version of the PG
backend it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
Well, it is open source, so there's no reason why someone couldn't make
these changes for 7.4 and also release a binary version in the mean time.
I have a copy of a 7.2 psql binary for linux
On Sat, 11 Jan 2003 03:34:22 -0500, Marc G. Fournier wrote:
On Sat, 11 Jan 2003, Lamar Owen wrote:
On Friday 10 January 2003 23:50, Marc G. Fournier wrote:
That was the aspect I feared ... almost an argument in itself for why
psql should be in gborg as a seperate project ;)
You've got
these changes for 7.4 and also release a binary version in the mean time.
I have a copy of a 7.2 psql binary for linux that that has some of the
7.3 psql improvments in it, sometimes it comes in very handy. I'd be
interested in helping out with this, though Christopher would probably
start
On Fri, 2003-01-10 at 12:30, Marc G. Fournier wrote:
Is there any way of fixing the following?
164_459_openacs= \d
ERROR: parser: parse error at or near .
164_459_openacs=
We've started to upgrade the client machines, before upgrading the server
itself, but it looks like the psql
Marc G. Fournier writes:
We've started to upgrade the client machines, before upgrading the server
itself, but it looks like the psql client isn't backwards compatible?
The meta-commands are not, because they now need to be schema aware.
--
Peter Eisentraut [EMAIL PROTECTED]
On Fri, 10 Jan 2003, Peter Eisentraut wrote:
Marc G. Fournier writes:
We've started to upgrade the client machines, before upgrading the server
itself, but it looks like the psql client isn't backwards compatible?
The meta-commands are not, because they now need to be schema aware.
How
Marc G. Fournier wrote:
On Fri, 10 Jan 2003, Peter Eisentraut wrote:
Marc G. Fournier writes:
We've started to upgrade the client machines, before upgrading the server
itself, but it looks like the psql client isn't backwards compatible?
The meta-commands are not, because they now
On Fri, 10 Jan 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Fri, 10 Jan 2003, Peter Eisentraut wrote:
Marc G. Fournier writes:
We've started to upgrade the client machines, before upgrading the server
itself, but it looks like the psql client isn't backwards
Marc G. Fournier wrote:
How hard would it be to add in a simple version check, like Robert Treat
suggested? Where, when you type in \d, it uses a pre-v7.3 schema if
attached to a pre-v7.3 server? With the changes that have gone in since
v7.3.1, we're going to need to do a v7.3.2
On Friday 10 January 2003 23:50, Marc G. Fournier wrote:
That was the aspect I feared ... almost an argument in itself for why psql
should be in gborg as a seperate project ;)
You've got to be kidding. The main command-line interface NEEDS to be part of
the main package. The solution is to
Right. It is just the _cruft_ factor that has prevented us from doing
it in the past.
Well, you could always have the function library for each different
version in a different shared lib which you load on demand.
Alternatively, follow the phpPgAdmin3 style and have a class 'Postgres71'
and
Bruce Momjian [EMAIL PROTECTED] writes:
Right. It is just the _cruft_ factor that has prevented us from doing
it in the past.
We've never before attempted to make psql cope with back-version
servers. It might be a good idea in future --- but it strikes me
as a new feature (and not a trivial
On Fri, 10 Jan 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Right. It is just the _cruft_ factor that has prevented us from doing
it in the past.
We've never before attempted to make psql cope with back-version
servers. It might be a good idea in future --- but it
20 matches
Mail list logo
