psql \l error

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 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

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, Pennsylvania 19026

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

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

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, and
we can not display a database-encoding of B_server when \l is used.)

--
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

"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

-----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

"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