Thread: psql \l error
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
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
> -----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
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 enableto 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
> 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
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
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
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
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
> > 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, Pennsylvania19026
> 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, Pennsylvania19026
> > > 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.typnameas \"Result\", .. oidvectortypes(p.proargtypes) as \"Arguments\" .. .. (2)
sendquery
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
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
> -----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
"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
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
> -----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
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, andwe can not display a database-encoding of B_server
when\l is used.)
--
Regard,
SAKAIDA Masaaki -- Osaka, Japan
"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
"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
> -----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,maybeThe latest version of libpq should be able to replace older versionof libpq without re-compilation and beable to talk to all backendsafter 6.4.The latest version of odbc driver should be able to replace those ofolder versionsand 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
"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
> -----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
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