Re: [HACKERS] [PATCHES] Quoting of psql \d output
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > Sent: 31 December 2003 02:41 > To: PostgreSQL-development > Cc: Tom Lane; Peter Eisentraut; [EMAIL PROTECTED] > Subject: Re: [HACKERS] [PATCHES] Quoting of psql \d output > > We have been discussing this patch on the patches list: > > ftp://candle.pha.pa.us/pub/postgresql/mypatches/fmtId > > In short, the patch removes quoting from \d displays when > quotes is not required (e.g. identifier is all lower case and > has no embedded spaces). Hi Bruce, Whilst I can see Peter's arguments are valid, the output from psql falls into a separate category IMO. These are not error messages, or notices but output specifically designed to describe the schema to the user, and as such I believe should be as clean as possible. We have in fact had similar discussions in pgAdmin - for example, pga1 quoted everything to be safe, and users complained because it 'uglified' output. Pga3 uses a modified version of fmtID() (to make it work with the wxString class instead of char arrays) and even now I hear the odd grumble about quotes when they actually need to be there! Wrt to Tom's objection, short of moving fmtID() into it's own source file, or duplicating it in psql (which I'm not advocating) I don't see that there is much we could do. I do think that the benefit outweighs the disadvantages however. +1 for applying the patch. Regards, Dave. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cache in plpgsql
ivan wrote: as new know plpgsql has special cache which remember too long (event non-existing tables (i mean old oid)) so i suggest to create same function only in plpgsql which would clear this cache, or sth like this ? for ie, where i drop table i would do plpgsql_clear_cache (); and when i will create one more time table with this same name plpgsql will not remeber wrong oid possible ? You obviously did not bother to search the archives on this. This will not solve the problem since the "cache" you're talking about is per backend local memory. So if one backend modifies the schema, how does it cause all other to forgt? Since the same problem exists in general for everything that uses SPI, the solution lies in there. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Preventing stack-overflow crashes (improving on max_expr_depth)
Tom Lane wrote: Comments? Really ugly but effective. Is ABS enough on a 64-bit architecture ? Or is better use labs ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] cache in plpgsql
why all backend can not using one cache, which would be always in real state ... or i can just clear only my cache, at first (if i know that this relation could has another oid) and then normal using relations ? or ... just turn off cache, because its strange to has possible using drop, create etc in function, but using only EXECUTE .. there must be same solution .. no ? On Wed, 31 Dec 2003, Jan Wieck wrote: > ivan wrote: > > >as new know plpgsql has special cache which remember too long (event > >non-existing tables (i mean old oid)) so i suggest to create same function > >only in plpgsql which would clear this cache, or sth like this ? > > > >for ie, where i drop table i would do plpgsql_clear_cache (); > >and when i will create one more time table with this same name plpgsql > >will not remeber wrong oid > > > >possible ? > > > > > > You obviously did not bother to search the archives on this. > > This will not solve the problem since the "cache" you're talking about > is per backend local memory. So if one backend modifies the schema, how > does it cause all other to forgt? Since the same problem exists in > general for everything that uses SPI, the solution lies in there. > > > Jan > > -- > > #==# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #== [EMAIL PROTECTED] # > > > > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Happy New Year ! :) and about gethostbyaddr
i didnt find gethostbyaddr, could be this in default implementation ? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cache in plpgsql
ivan wrote: why all backend can not using one cache, which would be always Variable sized shared memory with garbage collection for SPI plans? in real state ... or i can just clear only my cache, at first (if i know that this relation could has another oid) and then normal using relations ? As said, that is not sufficient. The user who does the DDL statement can as well reconnect to the database to recompile all saved plans. It is the 200 persistent PHP DB connections that suffer from not finding the index any more. or ... just turn off cache, because its strange to has possible using drop, create etc in function, but using only EXECUTE .. Do you have any numbers about how that would affect performance? Jan there must be same solution .. no ? On Wed, 31 Dec 2003, Jan Wieck wrote: ivan wrote: >as new know plpgsql has special cache which remember too long (event >non-existing tables (i mean old oid)) so i suggest to create same function >only in plpgsql which would clear this cache, or sth like this ? > >for ie, where i drop table i would do plpgsql_clear_cache (); >and when i will create one more time table with this same name plpgsql >will not remeber wrong oid > >possible ? > > You obviously did not bother to search the archives on this. This will not solve the problem since the "cache" you're talking about is per backend local memory. So if one backend modifies the schema, how does it cause all other to forgt? Since the same problem exists in general for everything that uses SPI, the solution lies in there. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Preventing stack-overflow crashes (improving on max_expr_depth)
Gaetano Mendola <[EMAIL PROTECTED]> writes: > Is ABS enough on a 64-bit architecture ? That was pseudocode, I wasn't actually planning to rely on a function. Something more like longdiff; diff = stack_base_ptr - &stack_top_loc; if (diff < 0) diff = -diff; if (diff > max) elog ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cache in plpgsql
but , all in all, do you think that now it is ok ? On Wed, 31 Dec 2003, Jan Wieck wrote: > ivan wrote: > > why all backend can not using one cache, which would be always > > Variable sized shared memory with garbage collection for SPI plans? > > > in real state ... or i can just clear only my cache, at first > > (if i know that this relation could has another oid) > > and then normal using relations ? > > As said, that is not sufficient. The user who does the DDL statement can > as well reconnect to the database to recompile all saved plans. It is > the 200 persistent PHP DB connections that suffer from not finding the > index any more. > > > > > or ... just turn off cache, because its strange to has possible > > using drop, create etc in function, but using only EXECUTE .. > > Do you have any numbers about how that would affect performance? > > > Jan > > > > > there must be same solution .. no ? > > > > > > On Wed, 31 Dec 2003, Jan Wieck wrote: > > > >> ivan wrote: > >> > >> >as new know plpgsql has special cache which remember too long (event > >> >non-existing tables (i mean old oid)) so i suggest to create same function > >> >only in plpgsql which would clear this cache, or sth like this ? > >> > > >> >for ie, where i drop table i would do plpgsql_clear_cache (); > >> >and when i will create one more time table with this same name plpgsql > >> >will not remeber wrong oid > >> > > >> >possible ? > >> > > >> > > >> > >> You obviously did not bother to search the archives on this. > >> > >> This will not solve the problem since the "cache" you're talking about > >> is per backend local memory. So if one backend modifies the schema, how > >> does it cause all other to forgt? Since the same problem exists in > >> general for everything that uses SPI, the solution lies in there. > >> > >> > >> Jan > >> > >> -- > >> > >> #==# > >> # It's easier to get forgiveness for being wrong than for being right. # > >> # Let's break this rule - forgive me. # > >> #== [EMAIL PROTECTED] # > >> > >> > >> > >> > >> ---(end of broadcast)--- > >> TIP 3: if posting/reading through Usenet, please send an appropriate > >> subscribe-nomail command to [EMAIL PROTECTED] so that your > >> message can get through to the mailing list cleanly > >> > > > -- > #==# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #== [EMAIL PROTECTED] # > > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings > ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Preventing stack-overflow crashes (improving on
--On Wednesday, December 31, 2003 11:20:49 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: Gaetano Mendola <[EMAIL PROTECTED]> writes: Is ABS enough on a 64-bit architecture ? That was pseudocode, I wasn't actually planning to rely on a function. Something more like long diff; diff = stack_base_ptr - &stack_top_loc; if (diff < 0) diff = -diff; if (diff > max) elog ... One archetecture that MIGHT be an issue (It's been 5+ years) is IBM 390 class under Z/OS. I'm not sure how they do stacks LER regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[HACKERS] using stp for dbt2 + postgresql
Hi Manfred, Just wanted to let you know I tried your patch-spinlock-i386 patch on our STP (our automated test platform) 8-way systems and saw a 5.5% improvement with Pentium III Xeons. If you want to see those results: PostgreSQL 7.4.1: http://khack.osdl.org/stp/285062/ PostgreSQL 7.4.1 w/ your patch: http://khack.osdl.org/stp/285087/ Mark ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Preventing stack-overflow crashes (improving on
On Wed, 31 Dec 2003, Tom Lane wrote: > > Is ABS enough on a 64-bit architecture ? > > That was pseudocode, I wasn't actually planning to rely on a function. > Something more like > > longdiff; FWIW, ISO has a ptrdiff_t, which may be useful here. Matthew. > diff = stack_base_ptr - &stack_top_loc; > if (diff < 0) > diff = -diff; > if (diff > max) > elog ... > > regards, tom lane > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > > ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cache in plpgsql
ivan wrote: but , all in all, do you think that now it is ok ? No, I don't. I just prefer complete solutions over patchwork. Jan On Wed, 31 Dec 2003, Jan Wieck wrote: ivan wrote: > why all backend can not using one cache, which would be always Variable sized shared memory with garbage collection for SPI plans? > in real state ... or i can just clear only my cache, at first > (if i know that this relation could has another oid) > and then normal using relations ? As said, that is not sufficient. The user who does the DDL statement can as well reconnect to the database to recompile all saved plans. It is the 200 persistent PHP DB connections that suffer from not finding the index any more. > > or ... just turn off cache, because its strange to has possible > using drop, create etc in function, but using only EXECUTE .. Do you have any numbers about how that would affect performance? Jan > > there must be same solution .. no ? > > > On Wed, 31 Dec 2003, Jan Wieck wrote: > >> ivan wrote: >> >> >as new know plpgsql has special cache which remember too long (event >> >non-existing tables (i mean old oid)) so i suggest to create same function >> >only in plpgsql which would clear this cache, or sth like this ? >> > >> >for ie, where i drop table i would do plpgsql_clear_cache (); >> >and when i will create one more time table with this same name plpgsql >> >will not remeber wrong oid >> > >> >possible ? >> > >> > >> >> You obviously did not bother to search the archives on this. >> >> This will not solve the problem since the "cache" you're talking about >> is per backend local memory. So if one backend modifies the schema, how >> does it cause all other to forgt? Since the same problem exists in >> general for everything that uses SPI, the solution lies in there. >> >> >> Jan >> >> -- >> >> #==# >> # It's easier to get forgiveness for being wrong than for being right. # >> # Let's break this rule - forgive me. # >> #== [EMAIL PROTECTED] # >> >> >> >> >> ---(end of broadcast)--- >> TIP 3: if posting/reading through Usenet, please send an appropriate >> subscribe-nomail command to [EMAIL PROTECTED] so that your >> message can get through to the mailing list cleanly >> -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] PL/Java issues
I have included the JDBC mailing list since I guess most Java developers are around here, but not necessarily on Hackers. Dave Cramer and I where discussing a few issues about the PL/Java implementation last night and would like to get more input and suggestions on the matter. The basic question is the definition of the lifetime of an object and it's identificaition when doing nested calls in this context. In the OO world, ideally a real world object is translated into one instance of a class. And complex structures are trees of instances, possibly of different classes. As an example, a sales order consists of the order header and a variable number of order lines. Therefore, per order we have one OH instance and several OL's. So far so good. Naturally, one Java object instance would correspond to one row in a database. If we now implement a stored procedure in PL/Java, that means that a pg_proc entry corresponds to a specific method of a specific class (its signature). But there is no obvious relationship between functions and tables or other objects. Because of that it is not implicitly clear if an incoming call to a method is meant for an existing instance or if a new one should be created. As an example, if a PL/Java trigger on the order header executes an SPI query on the order lines, a trigger on the order line (also in PL/Java) might now want to call a method on it's parent object (the order header that is waiting for the SPI result set). This should NOT result in another OH instance being created for the same logical OH. Probably it is not possible to map these things automatically while keeping the system flexible enough to be usefull. But is it feasable to require the programmer to provide glue code for every procedure that does all these things? How does Oracle attack this problem? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] using stp for dbt2 + postgresql
[EMAIL PROTECTED] wrote: > Hi Manfred, > > Just wanted to let you know I tried your patch-spinlock-i386 patch on > our STP (our automated test platform) 8-way systems and saw a 5.5% > improvement with Pentium III Xeons. If you want to see those results: > > PostgreSQL 7.4.1: > http://khack.osdl.org/stp/285062/ > > PostgreSQL 7.4.1 w/ your patch: > http://khack.osdl.org/stp/285087/ Impressive. Thanks. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PL/Java issues
Jan Wieck wrote: > As an example, if a PL/Java trigger on the order header executes an SPI > query on the order lines, a trigger on the order line (also in PL/Java) > might now want to call a method on it's parent object (the order header > that is waiting for the SPI result set). This should NOT result in > another OH instance being created for the same logical OH. > > Probably it is not possible to map these things automatically while > keeping the system flexible enough to be usefull. But is it feasable to > require the programmer to provide glue code for every procedure that > does all these things? How does Oracle attack this problem? How do our other procedural languages handle this problem? Are none of the OO or interface via OO? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PL/Java issues
Jan, In Oracle a call from sql into java (be it trigger, stored procedure or function), is required to be a call to a static method. Thus in Oracle all the work is left for the programmer to manage object instances and operate on the correct ones. While I don't like this limitation in Oracle, I can't see a better way of implementing things. Therefore if you want to operate on object instances you (in Oracle) need to code up object caches that can hold the instances across function calls so that two or more functions can operate on the same instance as necessary. What this implies to the implementation is that in order to be possible the multiple function calls need to run inside the same jvm (so you can access the static caches across the different calls). If every call created a new jvm instance in Oracle you couldn't do very much. The Oracle jvm essentially gives you one jvm per connection (although technically it is somewhere between one jvm for the whole server and one per connection - i.e. it has the memory and process footprint of a single jvm for the entire server, but appears to the user as a jvm per connection). Having one jvm per connection is important to limit multiple connections ability to stomp on each others data. Something similar could probably a done for postgres by having one jvm running, by having each postgres connection having a unique thread in that jvm and having each connection thread run with its own class loader instance so that separate classes (and thus static members) are loaded for each connection. thanks, --Barry Jan Wieck wrote: I have included the JDBC mailing list since I guess most Java developers are around here, but not necessarily on Hackers. Dave Cramer and I where discussing a few issues about the PL/Java implementation last night and would like to get more input and suggestions on the matter. The basic question is the definition of the lifetime of an object and it's identificaition when doing nested calls in this context. In the OO world, ideally a real world object is translated into one instance of a class. And complex structures are trees of instances, possibly of different classes. As an example, a sales order consists of the order header and a variable number of order lines. Therefore, per order we have one OH instance and several OL's. So far so good. Naturally, one Java object instance would correspond to one row in a database. If we now implement a stored procedure in PL/Java, that means that a pg_proc entry corresponds to a specific method of a specific class (its signature). But there is no obvious relationship between functions and tables or other objects. Because of that it is not implicitly clear if an incoming call to a method is meant for an existing instance or if a new one should be created. As an example, if a PL/Java trigger on the order header executes an SPI query on the order lines, a trigger on the order line (also in PL/Java) might now want to call a method on it's parent object (the order header that is waiting for the SPI result set). This should NOT result in another OH instance being created for the same logical OH. Probably it is not possible to map these things automatically while keeping the system flexible enough to be usefull. But is it feasable to require the programmer to provide glue code for every procedure that does all these things? How does Oracle attack this problem? Jan ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] [HACKERS] PL/Java issues
Barry, Ok, so if we drop this limitation then we leave it up to the architect to manage the caching problem themselves. The class loader issue is interesting, this would mean that each object static or otherwise would not be able to overwrite others data. --dc-- On Wed, 2003-12-31 at 19:34, Barry Lind wrote: > Jan, > > In Oracle a call from sql into java (be it trigger, stored procedure or > function), is required to be a call to a static method. Thus in Oracle > all the work is left for the programmer to manage object instances and > operate on the correct ones. While I don't like this limitation in > Oracle, I can't see a better way of implementing things. > > Therefore if you want to operate on object instances you (in Oracle) > need to code up object caches that can hold the instances across > function calls so that two or more functions can operate on the same > instance as necessary. What this implies to the implementation is that > in order to be possible the multiple function calls need to run inside > the same jvm (so you can access the static caches across the different > calls). If every call created a new jvm instance in Oracle you couldn't > do very much. The Oracle jvm essentially gives you one jvm per > connection (although technically it is somewhere between one jvm for the > whole server and one per connection - i.e. it has the memory and process > footprint of a single jvm for the entire server, but appears to the user > as a jvm per connection). Having one jvm per connection is important to > limit multiple connections ability to stomp on each others data. > Something similar could probably a done for postgres by having one jvm > running, by having each postgres connection having a unique thread in > that jvm and having each connection thread run with its own class loader > instance so that separate classes (and thus static members) are loaded > for each connection. > > thanks, > --Barry > > > Jan Wieck wrote: > > I have included the JDBC mailing list since I guess most Java developers > > are around here, but not necessarily on Hackers. > > > > Dave Cramer and I where discussing a few issues about the PL/Java > > implementation last night and would like to get more input and > > suggestions on the matter. > > > > The basic question is the definition of the lifetime of an object and > > it's identificaition when doing nested calls in this context. In the OO > > world, ideally a real world object is translated into one instance of a > > class. And complex structures are trees of instances, possibly of > > different classes. As an example, a sales order consists of the order > > header and a variable number of order lines. Therefore, per order we > > have one OH instance and several OL's. So far so good. Naturally, one > > Java object instance would correspond to one row in a database. > > > > If we now implement a stored procedure in PL/Java, that means that a > > pg_proc entry corresponds to a specific method of a specific class (its > > signature). But there is no obvious relationship between functions and > > tables or other objects. Because of that it is not implicitly clear if > > an incoming call to a method is meant for an existing instance or if a > > new one should be created. > > > > As an example, if a PL/Java trigger on the order header executes an SPI > > query on the order lines, a trigger on the order line (also in PL/Java) > > might now want to call a method on it's parent object (the order header > > that is waiting for the SPI result set). This should NOT result in > > another OH instance being created for the same logical OH. > > > > Probably it is not possible to map these things automatically while > > keeping the system flexible enough to be usefull. But is it feasable to > > require the programmer to provide glue code for every procedure that > > does all these things? How does Oracle attack this problem? > > > > > > Jan > > > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > -- Dave Cramer 519 939 0336 ICQ # 1467551 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Spinlock support for linux-hppa?
What is needed to provide spinlock support for linux on hppa? make[5]: Entering directory `/build/buildd/postgresql-7.4.1/build-tree/postgresql-7.4.1/src/backend/access/transam' ... hppa-linux-gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -pipe -I../../../../src/include -D_GNU_SOURCE -I/usr/include/tcl8.4 -I/usr/lib/R/include -c -o xlog.o xlog.c In file included from ../../../../src/include/storage/spin.h:50, from xlog.c:37: ../../../../src/include/storage/s_lock.h:543:2: #error PostgreSQL does not have native spinlock support on this platform. To continue the compilation, rerun configure using --disable-spinlocks. However, performance will be poor. Please report this to [EMAIL PROTECTED] make[5]: *** [xlog.o] Error 1 Full build log at http://buildd.debian.org/fetch.php?&pkg=postgresql&ver=7.4.1-1&arch=hppa&stamp=1072828455&file=log&as=raw -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "The LORD shall preserve thy going out and thy coming in from this time forth, and even for evermore." Psalms 121:8 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Spinlock support for linux-hppa?
On Thu, 2004-01-01 at 03:22, Oliver Elphick wrote: > What is needed to provide spinlock support for linux on hppa? I should add that 7.3.4 built OK. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "The LORD shall preserve thy going out and thy coming in from this time forth, and even for evermore." Psalms 121:8 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
