Thread

psql \l error

SAKAIDA Masaaki <sakaida@psn.co.jp> — 2000-05-02T02:47:21Z

Hi,

  There is a bug(?) report about \l command of psql.

(Example) PostgreSQL-7.0RC1

  A_server : configure                      (in USA)
  B_server : configure --enable--multibyte  (in Japan)

  By using the B_server's psql,

  prompt> psql -h A_server
  ERROR: Multibyte support must be enable to use this function

  prompt> export PGCLIENTENCODING='SQL_ASCII'
  prompt> psql -h A_server
  Welcome to psql, the PostgreSQL interactive terminal.

  Type:  \copyright for distribution terms
         \h for help with SQL commands
         \? for help on internal slash commands
         \g or terminate with semicolon to execute query
         \q to quit

  postgres=# \l
  ERROR:  No such function 'pg_encoding_to_char' with the 
          specified attributes

--
Regards,
SAKAIDA Masaaki  -- Osaka, Japan

Re: psql \l error

Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-02T04:34:51Z

SAKAIDA <sakaida@psn.co.jp> writes:
>   A_server : configure                      (in USA)
>   B_server : configure --enable--multibyte  (in Japan)

>   By using the B_server's psql,

prompt> psql -h A_server
>   ERROR: Multibyte support must be enable to use this function

This is evidently happening because psql's initial inquiry about the
database encoding fails.

Seems like it might be a good idea if the non-MULTIBYTE stub versions of
pg_encoding_to_char() and friends were to return default values (eg,
"SQL_ASCII") instead of erroring out.  A MULTIBYTE version of psql
really ought to be able to work with a non-MULTIBYTE server.

>   postgres=# \l
>   ERROR:  No such function 'pg_encoding_to_char' with the 
>           specified attributes

Hmm.  This is happening because 7.0 psql tries to display the encoding
of each database if psql was compiled with MULTIBYTE.

Here you are evidently talking to a pre-7.0 server (both because
a 7.0 server should have that function, even if the function
refuses to work ;-)) and because a 7.0 server does not spell the
'No such function' error message quite that way.

This one is a little nastier.  The only solution I could see that would
guarantee backwards compatibility is for psql not to try to display the
database encoding; that doesn't seem like a win.  I think there are
some other small incompatibilities between 7.0 psql and pre-7.0 servers
anyway, so eliminating this one by dumbing down \l is probably not
the way to proceed.

So, I'd suggest fixing the first issue (so that 7.0 MULTIBYTE psql works
with non-MULTIBYTE 7.0 server) but not trying to do anything about
MULTIBYTE psql with a pre-7.0 server.  Comments?

			regards, tom lane

RE: psql \l error

Hiroshi Inoue <inoue@tpf.co.jp> — 2000-05-02T05:50:42Z

> -----Original Message-----
> From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
> Behalf Of Tom Lane
> 
> SAKAIDA <sakaida@psn.co.jp> writes:
> >   A_server : configure                      (in USA)
> >   B_server : configure --enable--multibyte  (in Japan)
> 
> >   By using the B_server's psql,
> 
> >   postgres=# \l
> >   ERROR:  No such function 'pg_encoding_to_char' with the 
> >           specified attributes
> 
> Hmm.  This is happening because 7.0 psql tries to display the encoding
> of each database if psql was compiled with MULTIBYTE.
> 
> Here you are evidently talking to a pre-7.0 server (both because
> a 7.0 server should have that function, even if the function
> refuses to work ;-)) and because a 7.0 server does not spell the
> 'No such function' error message quite that way.
> 
> This one is a little nastier.  The only solution I could see that would
> guarantee backwards compatibility is for psql not to try to display the
> database encoding; that doesn't seem like a win.  I think there are
> some other small incompatibilities between 7.0 psql and pre-7.0 servers

 \df and \dd cause an ERROR: no such function 'oidvectortypes' ...
when 7.0 psql talks to pre-7.0 servers. I've noticed the fact but I
didn't know what should be done.
What kind of backward compatibity is required for psql etc..? 
Are there any documentations about it ?  Of cource it's preferable
that client application/libraries aren't tied to a specific version of
server application.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

Re: psql \l error

SAKAIDA Masaaki <sakaida@psn.co.jp> — 2000-05-02T06:58:31Z

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> SAKAIDA <sakaida@psn.co.jp> writes:
> >   A_server : configure                      (in USA)
> >   B_server : configure --enable--multibyte  (in Japan)
> 
> >   By using the B_server's psql,
> > 
> >   prompt> psql -h A_server
> >   ERROR: Multibyte support must be enable to use this function
> 
(snip)
>
> Seems like it might be a good idea if the non-MULTIBYTE stub versions of
> pg_encoding_to_char() and friends were to return default values (eg,
> "SQL_ASCII") instead of erroring out.  A MULTIBYTE version of psql
> really ought to be able to work with a non-MULTIBYTE server.

  I think so, too.

> >   postgres=# \l
> >   ERROR:  No such function 'pg_encoding_to_char' with the 
> >           specified attributes
> 
> Hmm.  This is happening because 7.0 psql tries to display the encoding
> of each database if psql was compiled with MULTIBYTE.
> 
> Here you are evidently talking to a pre-7.0 server (both because
> a 7.0 server should have that function, even if the function
> refuses to work ;-)) and because a 7.0 server does not spell the
> 'No such function' error message quite that way.

  Sorry, I have used a 6.5.3 as the A_server certainly. In the 
case of a 7.0,

  prompt> export PGCLIENTENCODING='SQL_ASCII'
  prompt> psql -h A_server
  postgres=# \l
  ERROR: Multibyte support must be enable to use this function

>
(snip)
> This one is a little nastier.  The only solution I could see that would
> guarantee backwards compatibility is for psql not to try to display the
> database encoding; that doesn't seem like a win.  I think there are
> some other small incompatibilities between 7.0 psql and pre-7.0 servers
> anyway, so eliminating this one by dumbing down \l is probably not
> the way to proceed.
> 
> So, I'd suggest fixing the first issue (so that 7.0 MULTIBYTE psql works
> with non-MULTIBYTE 7.0 server) but not trying to do anything about
> MULTIBYTE psql with a pre-7.0 server.  Comments?

  I consider that MULTIBYTE 7.0-psql must be able to access a 
pre-7.0 server. I don't think that it is so difficult to realize 
it between 6.5.x and 7.0.

  Problems except for \l are \df/\dd which Hiroshi Inoue already 
pointed out.

--
Regards,
SAKAIDA Masaaki  -- Osaka, Japan

Re: psql \l error

Tatsuo Ishii <t-ishii@sra.co.jp> — 2000-05-02T07:53:35Z

> This is evidently happening because psql's initial inquiry about the
> database encoding fails.
> 
> Seems like it might be a good idea if the non-MULTIBYTE stub versions of
> pg_encoding_to_char() and friends were to return default values (eg,
> "SQL_ASCII") instead of erroring out.  A MULTIBYTE version of psql
> really ought to be able to work with a non-MULTIBYTE server.
> 
> >   postgres=# \l
> >   ERROR:  No such function 'pg_encoding_to_char' with the 
> >           specified attributes
> 
> Hmm.  This is happening because 7.0 psql tries to display the encoding
> of each database if psql was compiled with MULTIBYTE.
> 
> Here you are evidently talking to a pre-7.0 server (both because
> a 7.0 server should have that function, even if the function
> refuses to work ;-)) and because a 7.0 server does not spell the
> 'No such function' error message quite that way.
> 
> This one is a little nastier.  The only solution I could see that would
> guarantee backwards compatibility is for psql not to try to display the
> database encoding; that doesn't seem like a win.  I think there are
> some other small incompatibilities between 7.0 psql and pre-7.0 servers
> anyway, so eliminating this one by dumbing down \l is probably not
> the way to proceed.
> 
> So, I'd suggest fixing the first issue (so that 7.0 MULTIBYTE psql works
> with non-MULTIBYTE 7.0 server) but not trying to do anything about
> MULTIBYTE psql with a pre-7.0 server.  Comments?

Sounds reasonable. I will fix the former but will leave the later as
it is.
--
Tatsuo Ishii

Re: psql \l error

Peter Eisentraut <e99re41@docs.uu.se> — 2000-05-02T08:26:49Z

On Tue, 2 May 2000, Tom Lane wrote:

> Seems like it might be a good idea if the non-MULTIBYTE stub versions of
> pg_encoding_to_char() and friends were to return default values (eg,
> "SQL_ASCII") instead of erroring out.  A MULTIBYTE version of psql
> really ought to be able to work with a non-MULTIBYTE server.

I've asked Tatsuo about this a long while ago but he didn't think it was
worth it.

> I think there are some other small incompatibilities between 7.0 psql
> and pre-7.0 servers anyway, so eliminating this one by dumbing down \l
> is probably not the way to proceed.

The oidvector thing is essentially a show stopper for this.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

RE: psql \l error

Peter Eisentraut <e99re41@docs.uu.se> — 2000-05-02T08:34:17Z

On Tue, 2 May 2000, Hiroshi Inoue wrote:

> What kind of backward compatibity is required for psql etc..? 

I thought psql was some sort of a reference application, so sticking to
prehistoric technology is not necessarily required. For example, outer
joins will simplify psql a great deal but that would really mean it stops
working for everybody else. Not sure.

The knowledge about the system catalogs is already pretty deep so keeping
track of changes across versions is similar to the initdb problem: either
we prohibit version differences outright (I thought that would be too
strict), we let it go until it fails (something that has been eliminated
for initdb), or we provide compabitibility. If someone wants to do the
latter, be my guest.

> Are there any documentations about it ?

Yes.

> Of cource it's preferable that client application/libraries aren't
> tied to a specific version of server application.

I agree. If someone has ideas that are not too ugly to live I'm sure we
could agree on them.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Re: psql \l error

SAKAIDA Masaaki <sakaida@psn.co.jp> — 2000-05-02T09:17:13Z

Peter Eisentraut <e99re41@DoCS.UU.SE> wrote:

> On Tue, 2 May 2000, Tom Lane wrote:
> 
> > I think there are some other small incompatibilities between 7.0 psql
> > and pre-7.0 servers anyway, so eliminating this one by dumbing down \l
> > is probably not the way to proceed.
> 
> The oidvector thing is essentially a show stopper for this.

  In my client software named PGBASH-2.1, I have dealt with "\l" 
compatibility problem as following.

 query1= SELECT pg_database.datname ..
         pg_encoding_to_char(pg_database.encoding) as \"Encoding\" ..
         ..
 query2= SELECT pg_database.datname ..
         pg_database.encoding as \"Encoding\" ..
         ..

  1. Make pset->quiet quiet mode.
  2. Send query1.
  3. Make pset->quiet original mode. 
  3. If error occurs then send query2.

--
Regards,
SAKAIDA Masaaki  -- Osaka, Japan

Re: psql \l error

Hiroshi Inoue <inoue@tpf.co.jp> — 2000-05-02T10:15:37Z

Peter Eisentraut wrote:

> On Tue, 2 May 2000, Hiroshi Inoue wrote:
>
> > What kind of backward compatibity is required for psql etc..?
>
> I thought psql was some sort of a reference application, so sticking to
> prehistoric technology is not necessarily required. For example, outer
> joins will simplify psql a great deal but that would really mean it stops
> working for everybody else. Not sure.
>
> The knowledge about the system catalogs is already pretty deep so keeping
> track of changes across versions is similar to the initdb problem:

Yes there's another example. PostgreSQL odbc driver wasn't able to talk
to 7.0 backend until recently due to the change int28 -> int2vector.
Now odbc driver could talk to all the backends from 6.2.
We may have to hold some reference table between system catalogs
and client appl/lib.

>
> > Are there any documentations about it ?
>
> Yes.

Unfortunately it's always painful for me to look for a documentation.
Could you please tell me where we could find it  ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

Re: psql \l error

Bruce Momjian <pgman@candle.pha.pa.us> — 2000-05-02T10:59:08Z

> > Seems like it might be a good idea if the non-MULTIBYTE stub versions of
> > pg_encoding_to_char() and friends were to return default values (eg,
> > "SQL_ASCII") instead of erroring out.  A MULTIBYTE version of psql
> > really ought to be able to work with a non-MULTIBYTE server.
> 
>   I think so, too.

Agreed.

> > This one is a little nastier.  The only solution I could see that would
> > guarantee backwards compatibility is for psql not to try to display the
> > database encoding; that doesn't seem like a win.  I think there are
> > some other small incompatibilities between 7.0 psql and pre-7.0 servers
> > anyway, so eliminating this one by dumbing down \l is probably not
> > the way to proceed.
> > 
> > So, I'd suggest fixing the first issue (so that 7.0 MULTIBYTE psql works
> > with non-MULTIBYTE 7.0 server) but not trying to do anything about
> > MULTIBYTE psql with a pre-7.0 server.  Comments?
> 
>   I consider that MULTIBYTE 7.0-psql must be able to access a 
> pre-7.0 server. I don't think that it is so difficult to realize 
> it between 6.5.x and 7.0.
> 
>   Problems except for \l are \df/\dd which Hiroshi Inoue already 
> pointed out.

We have allowed old psql's to talk to new servers, but not new psql's
talking to older servers.  For 7.0, I think they will have to match. 
There really isn't a way to fix the new oidvector changes for older
releases, and I don't think it is worth it, personally.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: psql \l error

Bruce Momjian <pgman@candle.pha.pa.us> — 2000-05-02T11:14:38Z

> Peter Eisentraut wrote:
> 
> > On Tue, 2 May 2000, Hiroshi Inoue wrote:
> >
> > > What kind of backward compatibity is required for psql etc..?
> >
> > I thought psql was some sort of a reference application, so sticking to
> > prehistoric technology is not necessarily required. For example, outer
> > joins will simplify psql a great deal but that would really mean it stops
> > working for everybody else. Not sure.
> >
> > The knowledge about the system catalogs is already pretty deep so keeping
> > track of changes across versions is similar to the initdb problem:
> 
> Yes there's another example. PostgreSQL odbc driver wasn't able to talk
> to 7.0 backend until recently due to the change int28 -> int2vector.
> Now odbc driver could talk to all the backends from 6.2.
> We may have to hold some reference table between system catalogs
> and client appl/lib.

The big reason for the change is that int2vector is now more than 8
int2's (now 16), so there may be internal changes as well as a name
change for applications.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: psql \l error

SAKAIDA Masaaki <sakaida@psn.co.jp> — 2000-05-02T13:21:36Z


> > > So, I'd suggest fixing the first issue (so that 7.0 MULTIBYTE psql works
> > > with non-MULTIBYTE 7.0 server) but not trying to do anything about
> > > MULTIBYTE psql with a pre-7.0 server.  Comments?
> > 
> >   I consider that MULTIBYTE 7.0-psql must be able to access a 
> > pre-7.0 server. I don't think that it is so difficult to realize 
> > it between 6.5.x and 7.0.
> > 
> >   Problems except for \l are \df/\dd which Hiroshi Inoue already 
> > pointed out.
> 
> We have allowed old psql's to talk to new servers, but not new psql's
> talking to older servers.  For 7.0, I think they will have to match. 
> There really isn't a way to fix the new oidvector changes for older
> releases, and I don't think it is worth it, personally.


  I don't know the details of oidvector. But new psql can talk to 
older server.

Ex.1)

 (1) select version();  ==> ver_no[] variable
 (2) If (ver_no[0] <= '6') then
        query <== SELECT t.typname as result ..
                   substr(oid8types(p.proargtypes),1,14) as arg ..
                   ..
     else 
        query <== SELECT t.typname as \"Result\", ..
                  oidvectortypes(p.proargtypes) as \"Arguments\" ..
                  ..
  (2) send query


Ex.2)

  (1) query1 <== SELECT t.typname as \"Result\", ..
                 oidvectortypes(p.proargtypes) as \"Arguments\" ..
                 ..
      query2 <== SELECT t.typname as result ..
                 substr(oid8types(p.proargtypes),1,14) as arg ..
                 ..

  (2) send query1
  (3) if an error occurs the send query2


--
Regard,
SAKAIDA Masaaki -- Osaka, Japan

Re: psql \l error

Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-02T15:39:07Z

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
>> I think there are some other small incompatibilities between 7.0 psql
>> and pre-7.0 servers anyway, so eliminating this one by dumbing down \l
>> is probably not the way to proceed.

> The oidvector thing is essentially a show stopper for this.

Yes, that was the other problem I was trying to recall.

Perhaps someday we might consider offering views on the system tables
that are defined in a way that keeps old applications happy.  However,
for something like the oidvector change there's just no way: an old app
that is looking at those fields is just not going to do the right thing
for functions or indexes with more than 8 arguments/columns, no matter
how we try to mask the change.  I think in these cases we are better off
to do what we did, ie, change the type name or whatever, so that those
old apps break in a fairly obvious way rather than failing subtly or
infrequently.

Looking at less generic answers, I suppose that psql could try to use
a 7.0-compatible query and fall back to a 6.5-compatible query if that
fails.  I imagine Peter will class this answer as "too ugly to live" ;-).
Certainly I don't have any interest in doing it, either, but maybe there
is someone out there who really needs a single psql to offer \df ability
with both generations of servers.  If so, that's the way to proceed.

			regards, tom lane

RE: psql \l error

Hiroshi Inoue <inoue@tpf.co.jp> — 2000-05-03T04:02:47Z

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> 
> > Peter Eisentraut wrote:
> > 
> > > On Tue, 2 May 2000, Hiroshi Inoue wrote:
> > >
> > > > What kind of backward compatibity is required for psql etc..?
> > >
> > > The knowledge about the system catalogs is already pretty 
> deep so keeping
> > > track of changes across versions is similar to the initdb problem:
> > 
> > Yes there's another example. PostgreSQL odbc driver wasn't able to talk
> > to 7.0 backend until recently due to the change int28 -> int2vector.
> > Now odbc driver could talk to all the backends from 6.2.
> > We may have to hold some reference table between system catalogs
> > and client appl/lib.
> 
> The big reason for the change is that int2vector is now more than 8
> int2's (now 16), so there may be internal changes as well as a name
> change for applications.
>

Yes I know the reason. It's only a example that changes of system
catalogs affects not only a backend application but also client libraries. 

Unfortunately I don't know the dependency between backend and
clients well. In addtion current release style of PostgreSQL that
releases both server and clients all together seems to let people
forget the independecy of clients.

In general client libraries/applications have to keep backward 
compatibility as possible,so it isn't enough for clients to be able to
talk to the latest version of PostgreSQL servers.

Comments ?  

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

Re: psql \l error

SAKAIDA Masaaki <sakaida@psn.co.jp> — 2000-05-03T12:30:42Z

"Hiroshi Inoue" <Inoue@tpf.co.jp> wrote:
> 
> In general client libraries/applications have to keep backward 
> compatibility as possible,so it isn't enough for clients to be able to
> talk to the latest version of PostgreSQL servers.
> 
> Comments ?  

  I agree with you. 

  User doesn't know how the specification of the server has been 
changed. Therefore, it is natural that user believe that new 
psql can talk to older server. Because backward compatibility is 
a reasonable rule of the upgrading in generic client software.

--
Regard,
SAKAIDA Masaaki -- Osaka, Japan

Re: psql \l error

Peter Eisentraut <peter_e@gmx.net> — 2000-05-03T23:10:59Z

Tom Lane writes:

> Looking at less generic answers, I suppose that psql could try to use
> a 7.0-compatible query and fall back to a 6.5-compatible query if that
> fails.  I imagine Peter will class this answer as "too ugly to live" ;-).

Until there is at least a glimpse of error codes I'd say it's "too
incorrect to live" ...


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

RE: psql \l error

Hiroshi Inoue <inoue@tpf.co.jp> — 2000-05-04T01:05:08Z

> -----Original Message-----
> From: SAKAIDA Masaaki [mailto:sakaida@psn.co.jp]
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> wrote:
> > 
> > In general client libraries/applications have to keep backward 
> > compatibility as possible,so it isn't enough for clients to be able to
> > talk to the latest version of PostgreSQL servers.
> > 
> > Comments ?  
> 
>   I agree with you. 
> 
>   User doesn't know how the specification of the server has been 
> changed. Therefore, it is natural that user believe that new 
> psql can talk to older server. Because backward compatibility is 
> a reasonable rule of the upgrading in generic client software.
>

Hmm,sorry for my poor English.
What I meant is a little different from yours.
What I wanted was to know official opinions about backward
compatibility of clients(not only psql)included in PostgreSQL's
release.

As for psql it isn't a generic client software as Peter mentioned.
It's a part of backend in a sense. At least it could talk to pre-7.0
backend and it isn't so critical that \l,\df and \dd doesn't work for 
pre-7.0 backends. I'm not so much eager to change psql myself.

There's already your pgbash that keeps backward compatibility.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

Re: psql \l error

SAKAIDA Masaaki <sakaida@psn.co.jp> — 2000-05-04T01:21:54Z

Peter Eisentraut <peter_e@gmx.net> wrote:

> Tom Lane writes:
> 
> > Looking at less generic answers, I suppose that psql could try to use
> > a 7.0-compatible query and fall back to a 6.5-compatible query if that
> > fails.  I imagine Peter will class this answer as "too ugly to live" ;-).
> 
> Until there is at least a glimpse of error codes I'd say it's "too
> incorrect to live" ...

  (Example)

  A_server(6.5.3)           B_server(7.0)
     |                         |
  ---+------------+------------+---- network
                  |
              C_server(7.0) + terminal

 * Telnet-login is not permitted in A_server and B_server.
 * Telnet-login is permitted in C_server.(We use C_server's psql)

 In this case, we can not use \l and \df command for A_server.

 Should we use 6.5.3 as a C server?

(If we use 6.5.3-psql, we can not use \df command for B_server, and
 we can not display a database-encoding of B_server when \l is used.)

--
Regard,
SAKAIDA Masaaki -- Osaka, Japan

Re: psql \l error

Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-04T01:47:37Z

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> What I wanted was to know official opinions about backward
> compatibility of clients(not only psql)included in PostgreSQL's
> release.

"Official" opinions?  I think we all just have our own opinions around
here :-).

> As for psql it isn't a generic client software as Peter mentioned.
> It's a part of backend in a sense. At least it could talk to pre-7.0
> backend and it isn't so critical that \l,\df and \dd doesn't work for 
> pre-7.0 backends. I'm not so much eager to change psql myself.

My opinion is that we'd be boxing ourselves in far too much to commit
to never having any system-catalog changes across versions.  So I'm
not particularly disturbed that functions that involve system catalog
queries sometimes are version-specific.  We should avoid breaking
essential functions of psql, but I don't think \df and friends are
essential...

			regards, tom lane

Re: psql \l error

SAKAIDA Masaaki <sakaida@psn.co.jp> — 2000-05-04T01:54:21Z

"Hiroshi Inoue" <Inoue@tpf.co.jp> wrote:

> > -----Original Message-----
> > From: SAKAIDA Masaaki [mailto:sakaida@psn.co.jp]
> > 
> > "Hiroshi Inoue" <Inoue@tpf.co.jp> wrote:
> > > 
> > > In general client libraries/applications have to keep backward 
> > > compatibility as possible,so it isn't enough for clients to be able to
> > > talk to the latest version of PostgreSQL servers.
> > > 
> > > Comments ?  
> > 
> >   I agree with you. 
> > 
> >   User doesn't know how the specification of the server has been 
> > changed. Therefore, it is natural that user believe that new 
> > psql can talk to older server. Because backward compatibility is 
> > a reasonable rule of the upgrading in generic client software.
> >
> 
> Hmm,sorry for my poor English.
> What I meant is a little different from yours.
> What I wanted was to know official opinions about backward
> compatibility of clients(not only psql)included in PostgreSQL's
> release.

  Sorry for my 10*poor English ;-)
  I understand what you meant.


> There's already your pgbash that keeps backward compatibility.

  In the next release pgbash-2.1(pgbash is a tool like bash+psql),

    pgbash(7.0-libpq) can talk to 6.5/7.0-server.
and pgbash(6.5-libpq) can talk to 6.5/7.0-server.

  pgbash will keep backward and forward compatibility as much as 
possible.

--
Regard,
SAKAIDA Masaaki -- Osaka, Japan

RE: psql \l error

Hiroshi Inoue <inoue@tpf.co.jp> — 2000-05-04T02:47:11Z

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > What I wanted was to know official opinions about backward
> > compatibility of clients(not only psql)included in PostgreSQL's
> > release.
> 
> "Official" opinions?  I think we all just have our own opinions around
> here :-).
>

Yes,but shouldn't there be some guidelines around here ?
For example,maybe
 The latest version of libpq should be able to replace older version
 of libpq without re-compilation and be able to talk to all backends
 after 6.4.
 The latest version of odbc driver should be able to replace those of
 older versions and be able talk to all backends after 6.2. 

I don't know about perl,jdbc,pgaccess etc....

> > As for psql it isn't a generic client software as Peter mentioned.
> > It's a part of backend in a sense. At least it could talk to pre-7.0
> > backend and it isn't so critical that \l,\df and \dd doesn't work for 
> > pre-7.0 backends. I'm not so much eager to change psql myself.
> 
> My opinion is that we'd be boxing ourselves in far too much to commit
> to never having any system-catalog changes across versions.  So I'm
> not particularly disturbed that functions that involve system catalog
> queries sometimes are version-specific.  We should avoid breaking
> essential functions of psql, but I don't think \df and friends are
> essential...
>

I don't think \df etc are essential for not generic client software either.
So I've not complained about it. I only wanted to confirm Peter and 
others' opinions on this occasion.  I apologize if my poor English
confused ML members.  

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

Re: psql \l error

Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-04T02:58:40Z

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> Yes,but shouldn't there be some guidelines around here ?
> For example,maybe
>  The latest version of libpq should be able to replace older version
>  of libpq without re-compilation and be able to talk to all backends
>  after 6.4.

As indeed it can...

It could be that we should have invested additional effort to make psql
able to execute all functions against both old and new backends, but
it seems to me that we had more important work to do.  There was
relatively little complaint about the fact that 6.4 psql (and all other
6.4 libpq-based applications) were not able to talk *at all* to pre-6.4
backends, so I'm surprised that we're discussing whether it's acceptable
that a few noncritical functions aren't cross-version compatible this
time around.

It's also worth noting that this is a major release --- it's not
entirely meaningless that we called it 7.0 and not 6.6.  We were willing
to break compatibility in more places than we would normally do, because
there were things that just had to be changed.  In the real world
I suspect that the datetime-related changes are going to cause far more
headaches for most users than the system catalog changes... but
sometimes progress has a price.

All just MHO, of course.

			regards, tom lane

RE: psql \l error

Hiroshi Inoue <inoue@tpf.co.jp> — 2000-05-04T04:44:58Z

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > Yes,but shouldn't there be some guidelines around here ?
> > For example,maybe
> >  The latest version of libpq should be able to replace older version
> >  of libpq without re-compilation and be able to talk to all backends
> >  after 6.4.
> 
> As indeed it can...
> 
> It could be that we should have invested additional effort to make psql
> able to execute all functions against both old and new backends, but
> it seems to me that we had more important work to do.  There was
> relatively little complaint about the fact that 6.4 psql (and all other
> 6.4 libpq-based applications) were not able to talk *at all* to pre-6.4
> backends, so I'm surprised that we're discussing whether it's acceptable

I know it but I think it's only an evidence that PostgreSQL was used
neither widely nor critically at that time.  As for me,I didn't consider
the production use of PostgreSQL at all at that time.
Now PostgreSQL is so much better than it was at that time and it
is and would be used widely and critically.
Now would it be allowed that libpq couldn't even talk to the previous
version ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

RE: psql \l error

Peter Eisentraut <peter_e@gmx.net> — 2000-05-04T16:36:06Z

Hiroshi Inoue writes:

> I don't think \df etc are essential for not generic client software either.
> So I've not complained about it. I only wanted to confirm Peter and 
> others' opinions on this occasion.

If someone wants to provide a reasonable fix for this situation I wouldn't
object. If too many people end up complaining I'll probably end up doing
it myself. ;)

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden