Re: [HACKERS] timestamp/date in ecpg
I started working on date/timestamp in ecpg. So far I can read date types from the DB and I can insert date into the DB. However there seems to be a bug in converting timestamp to ascii or vice versa. If anyone of you knows more about timestamp2tm etc. could you please have a look at function PGTYPEStimestamp_ttoa in pgtypeslib/timestamp.c? Hmm, maybe the transformation in the other direction is the culprit. What I do is call ts1 = PGTYPEStimestamp_atot(2000-7-12 17:34:29, NULL); followed by a text = PGTYPEStimestamp_ttoa (ts1); Needless to say the resulting text is not 2000-7-12 17:34:29. :-( Maybe some of you have an idea. I am willing to have a look at the functions, but am failing in finding directory pgtypeslib/ within $PGSQLD (version 7.3.2). Regards, Christoph ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] timestamp/date in ecpg
Hmm, maybe the transformation in the other direction is the culprit. What I do is call ts1 = PGTYPEStimestamp_atot(2000-7-12 17:34:29, NULL); followed by a text = PGTYPEStimestamp_ttoa (ts1); Needless to say the resulting text is not 2000-7-12 17:34:29. :-( I could not dig too deep into the code until now, but isn't there a leading zero missing 2000-07-12 17:34:29 Regards, Christoph ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ALTER TABLE / CLUSTER ON
On Fri, Mar 21, 2003 at 11:54:24AM +0800, Christopher Kings-Lynne wrote:
I just managed to break the CLUSTER ON patch:
Damn... I dunno how I managed to miss this. Please apply the attached
patch.
--
Alvaro Herrera (alvherre[a]dcc.uchile.cl)
Licensee shall have no right to use the Licensed Software
for productive or commercial use. (Licencia de StarOffice 6.0 beta)
Index: backend/commands/tablecmds.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/tablecmds.c,v
retrieving revision 1.69
diff -c -r1.69 tablecmds.c
*** backend/commands/tablecmds.c2003/03/20 18:52:47 1.69
--- backend/commands/tablecmds.c2003/03/21 15:38:37
***
*** 3835,3840
--- 3835,3841
{
elog(NOTICE, ALTER TABLE: table \%s\ is already being clustered on
index \%s\,
NameStr(rel-rd_rel-relname), indexName);
+ ReleaseSysCache(indexTuple);
heap_close(rel, AccessExclusiveLock);
return;
}
---(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] ALTER TABLE / CLUSTER ON
On Fri, Mar 21, 2003 at 11:21:16AM +0800, Christopher Kings-Lynne wrote: Does the new ALTER TABLE / CLUSTER ON syntax support the ONLY modifier - it isn't documented if it is?? I guess it's not really relevant is it? Oh, sorry, the command does not recurse. Should it? The whole CLUSTER thing does not recurse -- in fact that's why I didn't make the ALTER ... CLUSTER ON version do it, but maybe it should. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) El destino baraja y nosotros jugamos (A. Schopenhauer) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] cursors: SCROLL default, error messages
Folks, While doing some other cursor-related work, I noticed the following two issues: (1) Lack of NO SCROLL The SQL spec specifies that you should be able to specify NO SCROLL to DECLARE CURSOR to disallow bidirectional fetching on the cursor. We currently support the SCROLL syntax, but it had no significant effect on the behavior of the cursor. This was pretty easy to fix, so I implemented NO SCROLL. However, the SQL spec says that if neither SCROLL or NO SCROLL is specified, NO SCROLL should be implicit (SQL 2003 draft, 14.1, Syntax #7). This isn't how cursors have traditionally behaved in PostgreSQL -- backward and forward fetches have always been allowed, whether SCROLL was specified or not. Should we change this behavior to be spec compliant, or default to SCROLL if neither is specified? (2) Error handling If a DECLARE CURSOR is executed for a cursor name that already exists, the existing cursor is closed and replaced by the new cursor (a WARNING is issued). Similarly, a FETCH executed on a non-existent cursor yields a WARNING, not an ERROR. These are not good responses, IMHO: they seem illogical, and they conflict with the way that the vast majority of other commands behave. Should we change this? Cheers, Neil ---(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] [COMMITTERS] pgsql-server/ oc/src/sgml/manage-ag.sgml oc/sr ...
Tom Lane writes: for d in $(psql -l --somthing); do vacuum $d; done If you have a real shell (and know how to use it), sure. Is such a solution acceptable to all those Windows users we're hoping to attract? I don't know how Windows users typically manage their systems, but if they use batch files they can also write a similar loop with the native shell. (I just tried it.) My problem with a program that runs a command for all databases is that it is too rigid: What if you want to run maintenance only on some databases (owned by you, big/small, even/odd, starting with 'x')? --- Cannot use it, back to the manual approach. -- Peter Eisentraut [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] cursors: SCROLL default, error messages
Neil Conway [EMAIL PROTECTED] writes: The SQL spec specifies that you should be able to specify NO SCROLL to DECLARE CURSOR to disallow bidirectional fetching on the cursor. We currently support the SCROLL syntax, but it had no significant effect on the behavior of the cursor. This was pretty easy to fix, so I implemented NO SCROLL. Hm? As of CVS tip, SCROLL most definitely does something. (No problem here with adding the noise-word option, of course.) However, the SQL spec says that if neither SCROLL or NO SCROLL is specified, NO SCROLL should be implicit (SQL 2003 draft, 14.1, Syntax #7). This isn't how cursors have traditionally behaved in PostgreSQL -- backward and forward fetches have always been allowed, whether SCROLL was specified or not. Should we change this behavior to be spec compliant, or default to SCROLL if neither is specified? We already had that discussion. The agreed-to behavior is that we'll allow backwards fetch in the cases where it has historically worked (ie, where there's no additional overhead needed to support it) without requiring SCROLL. Requiring SCROLL in those cases would break many existing applications, without improving spec compliance in any way that any but pedants would care about. However, you will need to say SCROLL in the cases where overhead has to be added to support backwards fetch. If a DECLARE CURSOR is executed for a cursor name that already exists, the existing cursor is closed and replaced by the new cursor (a WARNING is issued). Similarly, a FETCH executed on a non-existent cursor yields a WARNING, not an ERROR. I agree that the second of these is bogus. I'm ambivalent about changing the first; it's odd but perhaps there are apps out there that depend on it. Any other opinions out there? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cursors: SCROLL default, error messages
On Fri, 2003-03-21 at 12:12, Tom Lane wrote: Hm? As of CVS tip, SCROLL most definitely does something. Sorry -- I noticed that it doesn't actually effect whether you can do backward fetches on the cursor, which is what I should have said. (No problem here with adding the noise-word option, of course.) Note that it won't be a noise word: if NO SCROLL is specified, an attempt to do a backward fetch on a non-scrollable cursor will yield an error. Should we change this behavior to be spec compliant, or default to SCROLL if neither is specified? We already had that discussion. Fair enough (I must have been sleeping :-) ). That behavior seems reasonable to me. Cheers, Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cursors: SCROLL default, error messages
Neil Conway [EMAIL PROTECTED] writes: On Fri, 2003-03-21 at 12:12, Tom Lane wrote: (No problem here with adding the noise-word option, of course.) Note that it won't be a noise word: if NO SCROLL is specified, an attempt to do a backward fetch on a non-scrollable cursor will yield an error. Hm. We could imagine a three-way option: NO SCROLL always error if fetch backwards nothing allow if plan supports it SCROLL allow, add overhead if needed to support The nothing case would deviate from the spec but would give backwards compatibility. regards, tom lane ---(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] cursors: SCROLL default, error messages
Tom Lane [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] writes: On Fri, 2003-03-21 at 12:12, Tom Lane wrote: (No problem here with adding the noise-word option, of course.) Note that it won't be a noise word: if NO SCROLL is specified, an attempt to do a backward fetch on a non-scrollable cursor will yield an error. Does the spec *require* an error, or merely say that backward fetches aren't required to work? Most specs don't impose many restrictions on what happens if the user does non conformant things. The SQL spec is a bit, er, nonstandard in that respect, but even for it I'm a bit surprised that it would explicitly say that if NO SCROLL is specified that backward fetches have to produce an error. The only possible rationale I could see for the spec imposing that kind of restriction would be a security concern if an middleware layer allocates a NO SCROLL cursor, pages forward, and then allows an upper tier to do unrestricted operations on that cursor trusting the database not to allow scrolling back. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cursors: SCROLL default, error messages
Greg Stark [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] writes: Note that it won't be a noise word: if NO SCROLL is specified, an attempt to do a backward fetch on a non-scrollable cursor will yield an error. Does the spec *require* an error, or merely say that backward fetches aren't required to work? Actually, what it says is that applications aren't allowed to issue backwards fetches if they didn't say SCROLL. This is one of the Syntax Rules for FETCH (in SQL92, but I imagine SQL99 is the same): 3) If the implicit or explicit fetch orientation is not NEXT, then the declare cursor CR shall specify SCROLL. AFAICS, our CVS-tip behavior is a reasonable superset of the spec. We don't have the NO SCROLL noiseword (which was not in SQL92 anyway), but otherwise I'm happy with what's there now. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] installcheck failure
I've been getting regression test failures (int8 and numeric) for the past couple of days. Looks like it is related to the recent to_char changes. Joe *** ./expected/int8.out Fri Sep 20 09:44:55 2002 --- ./results/int8.out Fri Mar 21 14:57:18 2003 *** *** 160,166 | 4567890123456789 |123 | 4567890123456789 !| -4567890123456789 (5 rows) SELECT '' AS to_char_6, to_char(q2, 'FMS')FROM INT8_TBL; --- 160,166 | 4567890123456789 |123 | 4567890123456789 !| --4567890123456789 (5 rows) SELECT '' AS to_char_6, to_char(q2, 'FMS')FROM INT8_TBL; *** *** 175,181 SELECT '' AS to_char_7, to_char(q2, 'FMTHPR') FROM INT8_TBL; to_char_7 | to_char ! ---+ | 456TH | 4567890123456789TH | 123RD --- 175,181 SELECT '' AS to_char_7, to_char(q2, 'FMTHPR') FROM INT8_TBL; to_char_7 | to_char ! ---+- | 456TH | 4567890123456789TH | 123RD *** *** 185,196 SELECT '' AS to_char_8, to_char(q2, 'SGth') FROM INT8_TBL; to_char_8 | to_char ! ---+- | + 456th | +4567890123456789th | + 123rd | +4567890123456789th !| -4567890123456789 (5 rows) SELECT '' AS to_char_9, to_char(q2, '0999') FROM INT8_TBL; --- 185,196 SELECT '' AS to_char_8, to_char(q2, 'SGth') FROM INT8_TBL; to_char_8 | to_char ! ---+-- | + 456th | + 4567890123456789th | + 123rd | + 4567890123456789th !| --4567890123456789 (5 rows) SELECT '' AS to_char_9, to_char(q2, '0999') FROM INT8_TBL; *** *** 275,285 SELECT '' AS to_char_17, to_char(q2, '99SG99') FROM INT8_TBL; to_char_17 | to_char ! +--- | + 456 | 456789+0123456789 | + 123 | 456789+0123456789 ! | 456789-0123456789 (5 rows) --- 275,285 SELECT '' AS to_char_17, to_char(q2, '99SG99') FROM INT8_TBL; to_char_17 | to_char ! + | +456 | 456789+0123456789 | +123 | 456789+0123456789 ! | -456789-0123456789 (5 rows) == *** ./expected/numeric.out Fri Mar 21 07:39:27 2003 --- ./results/numeric.out Fri Mar 21 14:57:21 2003 *** *** 765,778 ---+ | .000 | .000 !| -34338492.21539704700 | 4.310 |7799461.4119000 | 16397.0384910 | 93901.57763026000 !| -83028485.000 | 74881.000 !| -24926804.04504742000 (10 rows) SELECT '' AS to_char_6, to_char(val, 'FMS.999')FROM num_data; --- 765,778 ---+ | .000 | .000 !| --34338492.21539704700 | 4.310 |7799461.4119000 | 16397.0384910 | 93901.57763026000 !| --83028485.000 | 74881.000 !| --24926804.04504742000 (10 rows) SELECT '' AS to_char_6, to_char(val, 'FMS.999')FROM num_data; *** *** 792,823 SELECT '' AS to_char_7, to_char(val, 'FM.999THPR') FROM num_data; to_char_7 | to_char ! ---+-- !| 0. !| 0. | 34338492.215397047 !| 4.31 !| 7799461.4119 !| 16397.038491 !| 93901.57763026 | 83028485. !| 74881. | 24926804.04504742 (10 rows) SELECT '' AS
Re: [HACKERS] installcheck failure
Joe Conway [EMAIL PROTECTED] writes: I've been getting regression test failures (int8 and numeric) for the past couple of days. Looks like it is related to the recent to_char changes. Yeah, Bruce applied a to_char change that really wasn't ready, because (a) it didn't include the necessary regression updates, and (b) it introduced some new bugs. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] conversion problems with domains
PostgreSQL 7.3.2 CREATE DOMAIN testdom AS int4; CREATE TABLE testtab(testcol testdom); INSERT INTO testtab VALUES (1); INSERT INTO testtab VALUES (2); VACUUM ANALYZE testtab; SELECT * FROM testtab WHERE testcol 1; The select will give ERROR: convert_numeric_to_scalar: unsupported type 3381436 If no VACUUM ANALYZE is performed (no entry in pg_stats), the select will work ok. The select will also succeed, if testcol is compared to something different from 1. Defining a cast CREATE CAST(testdom as int4) WITHOUT FUNCTION AS IMPLICIT doesn't help. If I change the datatype UPDATE pg_attribute SET atttypid=(select oid from pg_type where typname = 'int4') WHERE atttypid=(select oid from pg_type where typname = 'testdom') AND attname='testcol' the select will work as expected. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PQescapeBytea on Win32
I have modified the patch to call it PQfreemem(), in case there are other
cases we need to free libpq memory.
Patch attached and applied.
---
Zeugswetter Andreas SB SD wrote:
Actually this isn't even working for me. I just compiled the libpq dll with
/MT (multithreaded), and I still get corruption in my app. I even tried
libpq compiled with multithreaded-debug (/MTd), which my app is using now,
and still same problem.
No, you need to use multithreaded DLL (/MD in VC6) for both the dll and your
program,
then it works.
But since that is not optimal (can't use debug runtime unless you have a second
debug dll (/MDd)), I also think a callback function would be good to have in
addition
to linking libpq.dll with /MD.
Informix e.g. supplies SqlFreeMem( void * MemAddr, int FreeType );
Andreas
---(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
--
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
Index: doc/src/sgml/libpq.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v
retrieving revision 1.113
diff -c -c -r1.113 libpq.sgml
*** doc/src/sgml/libpq.sgml 20 Mar 2003 06:23:30 - 1.113
--- doc/src/sgml/libpq.sgml 22 Mar 2003 03:27:47 -
***
*** 1151,1156
--- 1151,1175
/para
/listitem
/varlistentry
+
+ varlistentry
+ termfunctionPQfreemem/function/term
+ listitem
+ para
+Frees memory allocated by applicationlibpq/
+ synopsis
+ void PQfreemem(void *ptr);
+ /synopsis
+ /para
+
+ para
+Frees memory allocated by applicationlibpq/, particularly
+functionPQescapeBytea/function and functionPQunescapeBytea/function.
+It is needed by Win32, which can not free memory across
+DLL's, unless multithreaded DLL's (/MD in VC6) are used.
+ /para
+ /listitem
+ /varlistentry
/variablelist
/sect2
Index: src/interfaces/libpq/fe-exec.c
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.126
diff -c -c -r1.126 fe-exec.c
*** src/interfaces/libpq/fe-exec.c 10 Mar 2003 22:28:21 - 1.126
--- src/interfaces/libpq/fe-exec.c 22 Mar 2003 03:27:53 -
***
*** 284,289
--- 284,302
return buffer;
}
+
+ /*
+ *PQfreemem - safely frees memory allocated
+ *
+ * Needed mostly by Win32, unless multithreaded DLL (/MD in VC6)
+ * Used for freeing memory from PQescapeByte()a/PQunescapeBytea()
+ */
+ void PQfreemem(void *ptr)
+ {
+ free(ptr);
+ }
+
+
/*
* Space management for PGresult.
*
Index: src/interfaces/libpq/libpq-fe.h
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/libpq-fe.h,v
retrieving revision 1.89
diff -c -c -r1.89 libpq-fe.h
*** src/interfaces/libpq/libpq-fe.h 20 Mar 2003 06:23:30 - 1.89
--- src/interfaces/libpq/libpq-fe.h 22 Mar 2003 03:27:54 -
***
*** 254,259
--- 254,260
size_t *bytealen);
extern unsigned char *PQunescapeBytea(const unsigned char *strtext,
size_t *retbuflen);
+ extern void PQfreemem(void *ptr);
/* Simple synchronous query */
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] UltraSQL Win32 source code/patches?
How can I compile the UltraSQL version of PostgreSQL for Win32? I am looking for a Win32 version of PostgreSQL that does not depend on cygwin, and UltraSQL seems to work well. This site (http://techdocs.postgresql.org/guides/Windows) only points to the UltraSQL binaries (ftp://209.61.187.152/postgres/postgres_beta4.zip), but I read that PeerDirect, the company that did the UltraSQL port, also made its source code available. Does anyone know where I can find the UltraSQL source code or patches? Thanks, --RM http://byke.com - Free email, BMX links, Music, Art Culture and much more - Express yourself with a super cool email address from BigMailBox.com. Hundreds of choices. It's free! http://www.bigmailbox.com - ---(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] ALTER TABLE / CLUSTER ON
How can it recurse, actually - there won't be an index with the same name in the subtable? On Fri, 21 Mar 2003, Alvaro Herrera wrote: On Fri, Mar 21, 2003 at 11:21:16AM +0800, Christopher Kings-Lynne wrote: Does the new ALTER TABLE / CLUSTER ON syntax support the ONLY modifier - it isn't documented if it is?? I guess it's not really relevant is it? Oh, sorry, the command does not recurse. Should it? The whole CLUSTER thing does not recurse -- in fact that's why I didn't make the ALTER ... CLUSTER ON version do it, but maybe it should. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) El destino baraja y nosotros jugamos (A. Schopenhauer) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Nested transactions: low level stuff
I see no concurrency problems. If two or more backends visit the same tuple, they either write the same value to the same position which doesn't hurt, or one sees the other's changes which is a good thing. AFAIR, on multi-CPU platforms it's possible that second transaction could see COMMITTED state but still old (subtrans id) in xmin: it's not guaranteed that changes made on CPU1 (V1 was changed first, then V2 was changed) will appear at the same order on CPU2 (V2 may come first, then V1). Vadim _ Revere Data, LLC, formerly known as Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] installcheck failure
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I've been getting regression test failures (int8 and numeric) for the past couple of days. Looks like it is related to the recent to_char changes. Yeah, Bruce applied a to_char change that really wasn't ready, because (a) it didn't include the necessary regression updates, and (b) it introduced some new bugs. Yes, I gave Karel 2 days, and now I will clean it up. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] installcheck failure
Patch backed out. --- Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I've been getting regression test failures (int8 and numeric) for the past couple of days. Looks like it is related to the recent to_char changes. Yeah, Bruce applied a to_char change that really wasn't ready, because (a) it didn't include the necessary regression updates, and (b) it introduced some new bugs. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] UltraSQL Win32 source code/patches?
We are working on that feature in 7.4. I have the patch at: ftp://candle.pha.pa.us/pub/postgresql/mypatches but it is only for 7.2. --- Russ Mercer wrote: How can I compile the UltraSQL version of PostgreSQL for Win32? I am looking for a Win32 version of PostgreSQL that does not depend on cygwin, and UltraSQL seems to work well. This site (http://techdocs.postgresql.org/guides/Windows) only points to the UltraSQL binaries (ftp://209.61.187.152/postgres/postgres_beta4.zip), but I read that PeerDirect, the company that did the UltraSQL port, also made its source code available. Does anyone know where I can find the UltraSQL source code or patches? Thanks, --RM http://byke.com - Free email, BMX links, Music, Art Culture and much more - Express yourself with a super cool email address from BigMailBox.com. Hundreds of choices. It's free! http://www.bigmailbox.com - ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
