RE: [GENERAL] raw partition
It wouldn't be a very bad idea for systems where mmap is noticeably faster than read/write using syscalls. Unfortunately on some of those systems mmap is broken for multiple processes mapping the same file...:) Yeah, fair enough. But mmap works well on the more popular platforms used for PostgreSQL. And it can't *hurt* performance, and its probably worth doing simply so that PostgreSQL plays nicely with other applications using the VM resources on a particular system, instead of the fixed size buffer cache approach. But if someone wants to work on it, this would be fairly modest-sized project that only affects bufmgr... Interesting.. might be worth taking a look at.. - Andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] PL/java?
On Mon, Aug 27, 2001 at 09:40:13AM -0400, Alex Pilosov wrote: For the people who really really want PL/java, you can fake it with untrusted pl/perl (in 7.2) and Inline::Java. Off topics -- I am very interested in this plperlu Can plperlu be used in triggers? Any idea how I can go about using it before 7.2 is released? Thanks ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] raw partition
On Tue, Aug 28, 2001 at 12:02:08AM +1000, Andrew Snow wrote: What I think would be better would be moving postgresql to a system of using memory-mapped I/O. instead of the shared buffer cache, files would be directly memory-mapped and the OS would do the caching. I can't see this happening though because of platform dependancy, but I think its worth another look soon because many unix platforms support mmap(). I think it would improve the performance of disk-intensive tasks noticeably. Well, this has other problems. Consider tables that are larger than your system memory. You'd have to continuously map and unmap different sections. That can have odd side effects (witness mozilla on linux having 15,000 mapped areas or so...) You would still however get the advantage that you wouldn't have to copy the data from the disk buffers to user space, you simply get the disk buffer mapped into your address space. I think that for commonly used tables that are under 100K in size (most of the system tables), this is quite a workable idea. If you don't mind keeping them mapped the whole time. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ It would be nice if someone came up with a certification system that actually separated those who can barely regurgitate what they crammed over the last few weeks from those who command secret ninja networking powers. ---(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
[GENERAL] Re: SELECT FOR UPDATE
On 26 Aug 2001 13:50:16 -0700, Cody [EMAIL PROTECTED] wrote: I just finished reading Bruce M's book, so this thread confuses me, esp. Jan's posts. I take full heed of the need for application level user/thread management, but I was interested in using a parallel set-up in PG (however redundant that might be). Now that Jan has discounted SELECT...FOR UPDATE, is the best alternative using a central locking table (perhaps in conjunction with LISTEN NOTIFY)? Ironically, anyone who suggested using application level transactions would be torn apart at any of the places I've worked at--but that seems to be the gist of this thread. I cannot see a way to avoid deadlocks without an application level transaction component, since the central locking table idea would similarily lock the record forever if the first transaction failed to COMMIT or ROLLBACK. What is the saying: To the beginner, there are many options. To the wise, there are few. It seems to me that SELECT ... FOR UPDATE is not the way to go if it is possible that the selected record may be held for any length of time. The best way around this is going to depend on the application and resolution of conflicts will probably take place in the application. For instance, say you are storing web pages in the database, and you want a number of developers to be able to get pages from the database look at them, and possibly make changes and update the record. Your application might have some kind of sliding time-out scale from a 3-minute I see a typo to a 30-minute This really needs work. It would probably also remind the author before the time-out or possibly automatically save and re-acquire the lock if possible. So, the lock table would need a time-out field, and might also include a queue of people waiting for the record. This is just how I was thinking of it, and again I think it will depend on the application. At some point, you're not making a database, you're creating a cvs. Though a hybrid could be good ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] is it tcl problem or pg problem?
On Mon, Aug 27, 2001 at 11:12:40AM -0400, Tom Lane wrote: child process lost (is SIGCHLD ignored or trapped?) It's ignored in a backend, see src/backend/tcop/postgres.c. Current sources change the SIG_IGN setting to SIG_DFL, which may well solve your problem; you could try patching 7.1 sources that way and see if it helps. The real problem for me is that my column gets filled with the error line as well as the real data I want. I will try patching it. Do you mean to say that I will not get the error message with the patched version? Thanks ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] is it tcl problem or pg problem?
Have you tried running a dummy script that just returns say a number to
see if you get the same error? If I'm not mistaken, the return value from
exec in Tcl is the return value from the command you execute (i.e., 0 if
successful, etc). While you can print from the program, I'm not sure you
can capture just that value. You might also want to make sure that you are
doing a real exit from your script and not just letting it fall through
len morgan
- Original Message -
From: [EMAIL PROTECTED]
To: Len Morgan [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, August 27, 2001 10:43 AM
Subject: Re: [GENERAL] is it tcl problem or pg problem?
On Mon, Aug 27, 2001 at 09:07:34AM -0500, Len Morgan wrote:
Try:
catch { eval exec $NEW($1)} data
I'm not sure that this will solve the problem but executing commands
from
It did not :(
commands? Perhaps your date example was just an example (because you
can
use now()::date from within Postgres).
What I really want to do is run something like
at -f file 13:10 8/31/2001
and then capture at job number.
What I really want to get is at job number
and because I know perl better I am actually
going call a perl script from tcl. Perl
will call at and parse job number and
print it. Tcl will catch the number and
put in a database column
---(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: [GENERAL] is it tcl problem or pg problem?
Interesting. I think I might
be completely mistaken exec or eval exec in
tcl with the power of backtick operator
in perl.
Let's say my perl script is
$a=`$a`;
print $a
--
Then tcl $data variable gets not only
$a but also that error message
However I change perl to
---
$a=`$a`;
print $a;
exit 0
---
Then tcl $data variable only gets the
error message.
I must not exit 0! Or else I will
get nothing.
Perhaps the correct way to do is
to actually learn tcl to do what
perl is doing now but I would prefer
to stick with perl.
On Mon, Aug 27, 2001 at 10:14:39AM -0500, Len Morgan wrote:
Have you tried running a dummy script that just returns say a number to
see if you get the same error? If I'm not mistaken, the return value from
exec in Tcl is the return value from the command you execute (i.e., 0 if
successful, etc). While you can print from the program, I'm not sure you
can capture just that value. You might also want to make sure that you are
doing a real exit from your script and not just letting it fall through
len morgan
- Original Message -
From: [EMAIL PROTECTED]
To: Len Morgan [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, August 27, 2001 10:43 AM
Subject: Re: [GENERAL] is it tcl problem or pg problem?
On Mon, Aug 27, 2001 at 09:07:34AM -0500, Len Morgan wrote:
Try:
catch { eval exec $NEW($1)} data
I'm not sure that this will solve the problem but executing commands
from
It did not :(
commands? Perhaps your date example was just an example (because you
can
use now()::date from within Postgres).
What I really want to do is run something like
at -f file 13:10 8/31/2001
and then capture at job number.
What I really want to get is at job number
and because I know perl better I am actually
going call a perl script from tcl. Perl
will call at and parse job number and
print it. Tcl will catch the number and
put in a database column
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] raw partition
On Tue, Aug 28, 2001 at 12:50:15AM +1000, Andrew Snow wrote: Yeah, fair enough. But mmap works well on the more popular platforms used for PostgreSQL. And it can't *hurt* performance, and its probably Actually, it CAN hurt performance, even on some of the more popular platforms. worth doing simply so that PostgreSQL plays nicely with other applications using the VM resources on a particular system, instead of the fixed size buffer cache approach. Using mmap() vs a fixed buffer doesn't really make much difference. The access patterns are going to be pretty similar in both cases and the level of paging would be about the same. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ---(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: [GENERAL] Views in PgAccess
I solved it. Strangenly enough the versions of PgAccess included in Postgress and the one you can download from it homepage both claim to be 0.98.7, although they are different. As you said, the one bundled with Postgres does show the views. Thanks! Fernando Schapachnik writes: Any idea why Views do not show up in PgAccess Views tab (Postgres 7.1.2, PgAccess 0.98.7)? Any idea on how to solve it? Are you *sure* you are using the up-to-date pgaccess? I'd expect that misbehavior from a pre-7.1 pgaccess. regards, tom lane Fernando P. Schapachnik Planificación de red y tecnología VIA NET.WORKS ARGENTINA S.A. [EMAIL PROTECTED] Tel.: (54-11) 4323-3381 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[GENERAL] Foreign keys
If I create a columnA in a tableA that REFERENCES tableB(columnB) in another table, where column B is not null, does that imply a NOT NULL on my columnA? In other words, does it ensure that the value of A is in the set of values for B, or that the value of A is in the Bs unless A is null? Thanks, Neal Lindsay ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?)
I simply wonder, if any of the guys ever took a lesson in database design. If I had told such wonderful ideas on foreign keys to my professor i'd been thrown out the university imediatly. So if I am asked wheter to tage MySQL or PostgreSQL my answer is ... if you want to be fast and have a rather primitive db-design, only a few concurrent users, use MySQL. I all other cases take PostgreSQL. - Original Message - From: Jan Wieck [EMAIL PROTECTED] To: Tom Lane [EMAIL PROTECTED] Cc: PostgreSQL GENERAL [EMAIL PROTECTED] Sent: Monday, August 27, 2001 6:34 PM Subject: Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?) Tom Lane wrote: I have no doubt that MySQL's comparison page will keep pointing to this issue as a fatal limitation of PG long after it ceases to be a problem, however ;-) Oh yes, I'm pretty sure about that too. How many years took it for them to understand that transactions are useful at all? Now they have them and are so proud of it that they have 3 different table types supporting transactions. Well, I'm sure if you mix those types you'll not have any sort of cross-table deadlock detection, but anyhow, that's again some useless, CPU wasting feature because you can allways do the updates in the right order so you never risk a deadlock. From that I expect that it'll take them another 3-5 years to understand what a foreign key beside of the documentation purpose is good for. So far they still claim that it's a bad thing because it eat's performance for something you don't need if you program things in the right order. How to do that in a concurrent multiuser environment without doing exactly the same lookups with the same locks in the application is beyond my immagination, but they say so, so the typical MySQL user would surely bet the farm on it. Another interesting detail is, that only their MyISAM type is capable of (or planned for, I'm not 100% sure) hot-backups. But especially that table type has no transaction support. So it's right when they point out that you can do hot-backups, which is important for 24/7 setups. And they are right that MySQL has transaction support now. They just leave out the nasty little info that you cannot have transaction support in 24/7. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [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: [GENERAL] Foreign keys
On Mon, 27 Aug 2001, Neal Lindsay wrote: If I create a columnA in a tableA that REFERENCES tableB(columnB) in another table, where column B is not null, does that imply a NOT NULL on my columnA? In other words, does it ensure that the value of A is in the set of values for B, or that the value of A is in the Bs unless A is null? The latter. The constraint is satisfied by either a NULL or a value in B. (Note: For multiple column keys it gets more involved depending on the match type). ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [GENERAL] Re: SELECT FOR UPDATE
On 26 Aug 2001 13:50:16 -0700, Cody [EMAIL PROTECTED] wrote: I just finished reading Bruce M's book, so this thread confuses me, esp. Jan's posts. I take full heed of the need for application level user/thread management, but I was interested in using a parallel set-up in PG (however redundant that might be). Now that Jan has discounted SELECT...FOR UPDATE, is the best alternative using a central locking table (perhaps in conjunction with LISTEN NOTIFY)? It certainly does not discount SELECT...FOR UPDATE (SFU). You need some way to implement a mutex of sorts at the DB level, in order to insert new lock records into the lock table, and this is where SFU comes into play. But ANY long running DB level transaction is generally a bad thing. Ironically, anyone who suggested using application level transactions would be torn apart at any of the places I've worked at--but that This also is definately not app level transactions. I've implemented a lock-table system on a non-transactional database (Paradox) as well, and it's not a pretty thing :-) Generally two DB transactions take place to effect a checkout/checkin cycle, but what happens in between those two operations is completely outside the scope of any kind of transactioning. seems to be the gist of this thread. I cannot see a way to avoid deadlocks without an application level transaction component, since the central locking table idea would similarily lock the record forever if the first transaction failed to COMMIT or ROLLBACK. If the first transaction fails, it is no different than any other transaction failing to end in a timely manor: problems :-) This isn't a special case, the database can't ever completely compensate for a mis-behaved application, since it can't possibly know how the application is *intended* to work. Provided the app(s) are well-behaved, the common problem would be where the second transaction (either an update/unlock or abandon/unlock) never happens. As I and others have mentioned, this can be handled by including some sort of timeout field in the lock table, a periodic process to clean stale lock records from the database, and a tool to explicitly remove locks that can be run by a privileged user. In my experience, with a properly designed timeout system, stale locks rarely get in the way; with reliable client-side software, they don't even occur very often. Glen Parker [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: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
My favorite part of the artical was way way down at the end, where it briefly lists a few areas where postgres is still superior, minor little details such as full joins, sub-selects, views, unions, triggers, constraints, cursors... silly stuff like that :-) Glen ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?)
IMNSVHO the biggest argument against cross-DB queries is this useless extensibility in PostgreSQL. As soon as someone creates a data type, operator, aggregate or function, things get complicated. Have a data type acctno defined in both databases. And yes, we have operators for equalness in both DB's too. Now we do a cross-DB join and have two acctnos in the WHERE clause. First off, all these objects will have different OID's in the two system catalogs. Next, how do you know if the two types will at least have a similar external representation? And which of the two = operator functions will get called? Jan Stephan Szabo wrote: * You can access many databases from the same connection (depending of course on your privileges). = PostgreSQL does not allow you to access more than one database per connection. This makes the system much safer and allows for more robust design. How does that makes things safer etc etc? I believe that this is a genuine limitation. I hope the developers are honest why this limitation exists. There are probably valid and good reasons for this limitation but I don't think safer and more robust is a good one. If it really is, then it reduces my confidence level in Postgresql's access control design/internals. There are actually good reasons, the first being that the postgresql view is that databases are distinct entities (as opposed to schemas which will hopefully get there eventually) and as such it makes no sense to cross-db query. Right now, it's more of a limitation due to the fact that permissions to prevent object creation aren't there and that schemas aren't there, but once that's done I don't think this is much of a limitation anymore. In addition, there are questions about authentication that I think are tricky here, such as, we query a view, it uses another db, what user/password should be used? should we query the user? does the user even *know* what other db this view uses and why he's being prompted for a password? Every client program (even random libpq ones) potentially need to be able to handle an authentication request in response to a query? It's not a clear cut win. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] Re: Foreign keys
On Mon, Aug 27, 2001 at 02:31:01PM -0400, Neal Lindsay [EMAIL PROTECTED] wrote: If I create a columnA in a tableA that REFERENCES tableB(columnB) in another table, where column B is not null, does that imply a NOT NULL on my columnA? In other words, does it ensure that the value of A is in the set of values for B, or that the value of A is in the Bs unless A is null? Column A can have NULL values, in which case it passes the references condition. If you do want it to exist in column B, add a NOT NULL constraint to Column A. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] PL/java?
On 25 Aug 2001, Doug McNaught wrote: Can someone explain why the addition of a stored procedural language for MySQL made it as a Slashdot headline? Probably because /. uses MySQL (poor benighted fools ;) Back when Slashdot was designed, Postgres was crap. We have old versions we're still getting rid of, and they're the biggest headache in the world. I've actually used \d and the back-end crashed. Usually this happens when the database has handled around 15k queries in one session, or someone, somewhere, even looks in the direction of a row that is anywhere near the 8k limit. It's very simple. Anything before postgres 7.1 was complete, utter crap. Slashdot was around way before 7.1, hence mysql. Personally, I laud their decision. I mean, I've never had show tables crash a mysql database, yet \d (or even a single-table, no where clause select) can crash the back end of postgres 7.0.3. We can't even do bulk inserts on these tables (20k rows) because the back end inexplicably dies before it finishes. I'm talking about insert statements, not postgres proprietary COPY. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | Most of our lives are about proving something, either to | | ourselves or to someone else. | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
= In MySQL you have to repair your tables manually if corruption occurs. PostgreSQL is coded so that corruption cannot occur. Unless you're running pre-7.1, in which doing any of the following may corrupt an entire database so badly that pg_dumpall crashes on it. * Table A. Create mirror table B. Insert into B. Drop A. Rename B to A. Watch backend crash randomly, corrupting said table to unrecognizable form - hence corrupting entire database. This may only happen once every 1000 times the process is repeated, but *will* occur eventually. This happened more in 6.5. * Select, insert, update, whatever. Eventually, postgrees will report that the back end has exited unexpectedly. This is easier to repeat on an installation serving many simultaneous connections, especially if any database has been affected by: * Inserting any row with a total column length of 8k or higher, minus row/column overhead. For even more fun, insert a row of arbitrary length, or use multiple text columns. * Selecting, updating, or even remotely touching any table which has an example of the above. Yes, this means that you can't even delete the offending row, or pg_dump the database to remove it manually. What about pg_dump, you say? Sure, that'll work. Get the tables that aren't corrupted, like you know which ones they are. Then all you have to do is not give a rat's ass about the data in the table that *is* corrupted. Sounds easy, right? All of this vanished like smoke when 7.1 came out. In my opinion, 7.1 is the first real release of postgres, and hence Mysql is fully justified in most of its accusations/comparisons. Until 7.1, postgres didn't have a snowball's chance in hell at beating mysql on the stability front, now the odds are a little more even. Either way, don't dare sit there and tell me postgres doesn't corrupt tables. I would actually prefer a utility to integrity check/repair a corrupted table into something that the database could read, rather than give the data up for a loss and run for our backups, as we have been doing. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | Most of our lives are about proving something, either to | | ourselves or to someone else. | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] Re: !! Newbie question!!!! connecting to multiple databases
On Fri, 24 Aug 2001 21:53:00 GMT, uncleleo [EMAIL PROTECTED] wrote: I am attemping to create multiple databases with Postgresql ver. 7.0.3 running on Mandrake 8.0 rpm. The tool that I am using is Pgadmin ver 7.1.0. Can someone tell me how I can connect to different databases in a single select statement? Such as, I have a database named Customer and another named Products. I wish to Select from table A in the Customer database and table A in Products database. I know that its possible in SQL Server and other databases. This is not possible as of postgres 7.1.3 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?)
On Mon, 27 Aug 2001, Andre Schnabel wrote: I simply wonder, if any of the guys ever took a lesson in database design. If I had told such wonderful ideas on foreign keys to my professor i'd been thrown out the university imediatly. I agree. While you're at it, tell him you won't have a corresponding drop for every create, and that outer joins are useless. Then, while he's laughing at you, tell him you'll restrict data to 8k per row, and that you won't truncate inserted data, because people will always follow the rules. Then, as he's rolling on the floor clutching his stomach, tell him you'll add cool stuff like table inheritance before even *considering* adding the things listed previously. Now he's died laughing. Great. You've killed your professor. Bastard. Now. Consider that until 7.1, all of the above was true about Postgres. Hmm... Bad DB design... what was that you were saying again? -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | Most of our lives are about proving something, either to | | ourselves or to someone else. | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(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
