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 T
[EMAIL PROTECTED] writes:
> 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 shipp
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
>>>[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 a
-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 th
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 versi
> 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 i
[EMAIL PROTECTED] wrote:
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 realized
-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
> 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
> star
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 ;)
>>
>>
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 to be kidding. The main command-line interface NEEDS to b
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
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
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 trivia
> 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
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
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 ba
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, b
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.
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, 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 t
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 client isn't backwards compatible?
--
23 matches
Mail list logo
