Re: [PATCHES] WIP: pl/pgsql cleanup
Tom Lane wrote: Still a few bricks shy of a load I fear [...] My apologies; thanks for the code review. regression=# create or replace function foo() returns int language plpgsql as $$ regression$# begin regression$# return ; regression$# end$$; CREATE FUNCTION regression=# select foo(); server closed the connection unexpectedly If you're going to stick a NULL into the return's expression then you'd better check for same when it's used. Right. Better I think is to only allow a missing RETURN expression for functions declared to return void anyway; that catches the mistake at compile-time. I've implemented this behavior in the revised patch. The error message in this scenario is still a little poor: create function missing_return_expr() returns int as $$ begin return ; end;$$ language plpgsql; ERROR: syntax error at end of input at character 8 QUERY: SELECT CONTEXT: SQL statement in PL/PgSQL function "missing_return_expr" near line 2 LINE 1: SELECT ^ Is it worth putting in a special-case to look for an unexpected ';' in either the RETURN production or read_sql_construct() ? What I was actually intending to check when I ran into that is why some of the error paths in your FOR-loop rewrite use plpgsql_error_lineno = $1; while others have plpgsql_error_lineno = plpgsql_scanner_lineno(); I suspect the former is more appropriate, at least for errors that reference the FOR variable and not some other part of the statement. Also why the inconsistent use of yyerror() vs ereport()? Sorry, both of these result from sloppiness on my part: I think the code was originally correct, but I tried to refactor some of the more complex parts of the FOR statement production into a separate function, and eventually wasn't able to (because of the `forvariable' union member). When I gave up and reverted the code, I obviously wasn't careful enough. Attached is a revised patch. -Neil plpgsql_cleanup-34.patch.gz Description: application/gzip ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Bibliography updates
On Sun, 2005-02-20 at 11:18 -0700, Michael Fuhr wrote: > The attached patch updates three books in the Bibliography to their > most recent editions. Patch applied to HEAD. Thanks. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] pg_ctl reference page
On Sun, 2005-02-20 at 19:56 +0100, Magnus Hagander wrote: > It seems the pg_ctl reference page is missing the documentation for > register/unregister for windows services. Attached is a patch taht adds > this (be sure to verify the markup before any commit, though!) Applied to HEAD and REL8_0_STABLE. Thanks for the patch. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Patch for disaster recovery
Bruce Momjian writes: > Tom Lane wrote: >> Not sure where this leads to, but it's not leading to an undocumented >> one-line hack in tqual.c, and definitely not *that* one-line hack. > Sorry, here is the proper change I just applied: > /* This is to be used only for disaster recovery and requires serious > analysis. */ > #ifndef MAKE_ALL_TUPLES_VISIBLE > return false; > #else > return true; > #endif AFAICS this has no value whatsoever. Assuming that someone has a disaster recovery problem on their hands, how likely is it that they will know that that code is there, or be able to turn it on (most users don't compile from source anymore), or be able to use it effectively, given the complete lack of documentation? As is, this is of value only to someone familiar with the code, and such a someone could go in and modify the logic for themselves just as easily as turn on a #define. I think the only real effect of this patch will be to confuse people who are reading the source code. tqual.c is already complicated and fragile enough --- it doesn't need conditionally compiled "features" that we can't even explain the use of. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Patch for disaster recovery
Bruno Wolff III wrote: > On Sun, Feb 20, 2005 at 09:43:11 -0500, > Bruce Momjian wrote: > > > > We regularly have people on IRC who delete data and then want to recover > > it. By having the define it makes it easier for us to help them without > > them having to add actual C code. > > > > Does that make sense? > > You aren't going to get a consistant snapshot if you get back all of the > deleted rows. With autovacuum it is going to get harder to do this, because > accidentally making large changes in a table is going to trigger a vacuum. Right, but as far as I remember the vacuum isn't going to reuse the rows. Rather, it is just going to mark them for later reuse. > It seems like the right way to do this is a recovery using the PITR > system and putting effort into making that easier is the way to go. You are assuming someone is running PITR already, which they might not. This define is just so we can help folks recover deleted stuff under our guidance. Also, I think a general GUC mechanism is too dangerous. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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]
Re: [PATCHES] Patch for disaster recovery
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Not sure where this leads to, but it's not leading to an undocumented > >> one-line hack in tqual.c, and definitely not *that* one-line hack. > > > Sorry, here is the proper change I just applied: > > > /* This is to be used only for disaster recovery and requires serious > > analysis. */ > > #ifndef MAKE_ALL_TUPLES_VISIBLE > > return false; > > #else > > return true; > > #endif > > AFAICS this has no value whatsoever. Assuming that someone has a > disaster recovery problem on their hands, how likely is it that they > will know that that code is there, or be able to turn it on (most > users don't compile from source anymore), or be able to use it > effectively, given the complete lack of documentation? As is, this > is of value only to someone familiar with the code, and such a someone > could go in and modify the logic for themselves just as easily as > turn on a #define. > > I think the only real effect of this patch will be to confuse people > who are reading the source code. tqual.c is already complicated and > fragile enough --- it doesn't need conditionally compiled "features" > that we can't even explain the use of. I need a note somewhere to remember where to tell people to modify the code to recovery something. Do you have a better idea? You want just a comment rather than a define? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 7: don't forget to increase your free space map settings
[PATCHES] CSV multiline final fix
Well, in response to the huge number (0) of comments on my POC patch to
fix this, I prepared the attached patch, which improves on my previous
effort a bit (there was one obscure failure case which is now handled).
Basically, all the required logic is in a new function CopyReadLineCSV()
which is almost but not quite like CopyReadLine(). The new function
keeps just enough state to know if a line ending sequence (CR, CRLF, or
LF) is part of a quoted field or not. This gets rid of the need for
special casing embedded line endings on input elsewhere, so that is
removed, as is the warning about them on output that we added back in
december (as we then thought just before release). Lastly, the docs are
also patched.
Also attached is my tiny test file - maybe we need to cover this in
regression tests?
cheers
andrew
diff -c -r ../../pgbf/root/REL8_0_STABLE/pgsql/doc/src/sgml/ref/copy.sgml
./doc/src/sgml/ref/copy.sgml
*** ../../pgbf/root/REL8_0_STABLE/pgsql/doc/src/sgml/ref/copy.sgml Mon Jan
3 19:39:53 2005
--- ./doc/src/sgml/ref/copy.sgmlSun Feb 20 19:18:54 2005
***
*** 496,508
CSV mode will both recognize and produce CSV files with quoted
values containing embedded carriage returns and line feeds. Thus
! the files are not strictly one line per table row like text-mode
! files. However, PostgreSQL will reject
! COPY input if any fields contain embedded line
! end character sequences that do not match the line ending
! convention used in the CSV file itself. It is generally safer to
! import data containing embedded line end characters using the
! text or binary formats rather than CSV.
--- 496,503
CSV mode will both recognize and produce CSV files with quoted
values containing embedded carriage returns and line feeds. Thus
! the files are not strictly one line per table row as are text-mode
! files.
***
*** 513,518
--- 508,515
might encounter some files that cannot be imported using this
mechanism, and COPY might produce files that other
programs cannot process.
+ It is generally safer to import data using the text or binary formats,
+if possible, rather than using CSV format.
diff -c -r ../../pgbf/root/REL8_0_STABLE/pgsql/src/backend/commands/copy.c
./src/backend/commands/copy.c
*** ../../pgbf/root/REL8_0_STABLE/pgsql/src/backend/commands/copy.c Fri Dec
31 16:59:41 2004
--- ./src/backend/commands/copy.c Sun Feb 20 13:40:56 2005
***
*** 98,104
static EolType eol_type; /* EOL type of input */
static intclient_encoding;/* remote side's character encoding */
static intserver_encoding;/* local encoding */
- static bool embedded_line_warning;
/* these are just for error messages, see copy_in_error_callback */
static bool copy_binary; /* is it a binary copy? */
--- 98,103
***
*** 140,145
--- 139,145
char *delim, char *null_print, bool csv_mode, char *quote, char *escape,
List *force_notnull_atts);
static bool CopyReadLine(void);
+ static bool CopyReadLineCSV(char * quote, char * escape);
static char *CopyReadAttribute(const char *delim, const char *null_print,
CopyReadResult *result, bool *isnull);
static char *CopyReadAttributeCSV(const char *delim, const char *null_print,
***
*** 1191,1197
attr = tupDesc->attrs;
num_phys_attrs = tupDesc->natts;
attr_count = list_length(attnumlist);
- embedded_line_warning = false;
/*
* Get info about the columns we need to process.
--- 1191,1196
***
*** 1718,1724
ListCell *cur;
/* Actually read the line into memory here */
! done = CopyReadLine();
/*
* EOF at start of line means we're done. If we see
EOF after
--- 1717,1723
ListCell *cur;
/* Actually read the line into memory here */
! done = csv_mode ? CopyReadLineCSV(quote, escape) :
CopyReadLine();
/*
* EOF at start of line means we're done. If we see
EOF after
***
*** 2194,2199
--- 2193,2448
return result;
}
+ /*
+ * Read a line for CSV copy mode. Differences from standard mode:
+ * . CR an NL are not special inside quoted fields - they just get added
+ * to the buffer.
+ * . \ is not magical except as the start of the end of data marker.
+ *
+ */
+
+ static bool
+ CopyReadLineCSV(char * quote, char * escape)
+ {
+ boolresult;
+ boolchange_encoding = (client_encoding != server_encoding);
+
Re: [PATCHES] Change < to -f in examples with input files
David Fetter wrote: > Please find enclosed a patch, per Dennis Björklund, that uses -f for > input files rather than <. This makes error messages, &c. more > expressive. To be portable, options must be before non-option arguments, so you need to rearrange the command-line arguments in the examples if you want to make that change. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Change < to -f in examples with input files
Folks, Please find enclosed a patch, per Dennis Björklund, that uses -f for input files rather than <. This makes error messages, &c. more expressive. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! Index: doc/src/sgml/backup.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/backup.sgml,v retrieving revision 2.55 diff -c -r2.55 backup.sgml *** doc/src/sgml/backup.sgml22 Jan 2005 22:56:35 - 2.55 --- doc/src/sgml/backup.sgml20 Feb 2005 20:45:07 - *** *** 177,183 The resulting dump can be restored with psql: ! psql template1 < infile (Actually, you can specify any existing database name to start from, but if you are reloading in an empty cluster then template1 --- 177,183 The resulting dump can be restored with psql: ! psql template1 -f infile (Actually, you can specify any existing database name to start from, but if you are reloading in an empty cluster then template1 *** *** 1210,1216 gmake install initdb -D /usr/local/pgsql/data postmaster -D /usr/local/pgsql/data ! psql template1 < backup See about ways to start and stop the --- 1210,1216 gmake install initdb -D /usr/local/pgsql/data postmaster -D /usr/local/pgsql/data ! psql template1 -f backup See about ways to start and stop the ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [BUGS] BUG #1466: #maintenace_work_mem = 16384
>>> The proposed test on Redirect_stderr looks pretty fishy too; for one >>> thing it will almost certainly not be the right thing >inside the stderr >>> logger subprocess itself. > >> Could you explain further what the issue is there? > >Inside the logger subprocess, Redirect_stderr is guaranteed true (since >it'll be inherited from the postmaster) and therefore the proposed >change ensures that anything the logger might want to complain about >goes to the original stderr, ie, into the bit bucket rather than >someplace useful. Perhaps something like > > if ((!Redirect_stderr || am_syslogger) && pgwin32_is_service()) > >would be reasonable. Here is an updated patch, that should take care of this. Tested that it solves the problem reported. >> There is special code in the send_message_to_server_log >function to make >> sure it's written directly to the file. > >If the logger is complaining, it's quite possibly because it's >unable to >write to its file. Now that you mention it, doesn't this code go into >infinite recursion if write_syslogger_file_binary() tries to ereport? > I haven't looked at this part, it appears a separate (but closely related) issue. Perhaps Andreas can comment on this? //Magnus stderr.patch Description: stderr.patch ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] pg_ctl reference page
It seems the pg_ctl reference page is missing the documentation for register/unregister for windows services. Attached is a patch taht adds this (be sure to verify the markup before any commit, though!) //Magnus pgctlref.patch Description: pgctlref.patch ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] Bibliography updates
The attached patch updates three books in the Bibliography to their most recent editions. Publication information obtained from the following sites: The Practical SQL Handbook, Bowman et al http://www.aw-bc.com/catalog/academic/product/0,1144,0201703092,00.html An Introduction to Database Systems, Date http://www.aw-bc.com/catalog/academic/product/0,1144,0321197844,00.html Fundamentals of Database Systems, Elmasri & Navathe http://www.aw-bc.com/catalog/academic/product/0,1144,0321122267,00.html -- Michael Fuhr http://www.fuhr.org/~mfuhr/ Index: doc/src/sgml/biblio.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/biblio.sgml,v retrieving revision 1.20 diff -c -r1.20 biblio.sgml *** doc/src/sgml/biblio.sgml29 Nov 2003 19:51:36 - 1.20 --- doc/src/sgml/biblio.sgml20 Feb 2005 18:02:24 - *** *** 23,33 SQL Reference Books Reference texts for SQL features. ! The Practical SQL Handbook ! Bowman et al, 1996 ! Using Structured Query Language ! Third Edition Judith --- 23,33 SQL Reference Books Reference texts for SQL features. ! The Practical SQL Handbook ! Bowman et al, 2001 ! Using SQL Variants ! Fourth Edition Judith *** *** 42,55 Darnovsky ! 0-201-44787-8 ! 1996 ! Addison-Wesley ! 1996 ! Addison-Wesley Longman, Inc. --- 42,54 Darnovsky ! 0-201-70309-2 ! 2001 ! Addison-Wesley Professional ! 2001 *** *** 79,108 ! An Introduction to Database Systems ! Date, 1994 ! Sixth Edition C. J. Date ! Volume 1 ! 1994 Addison-Wesley ! 1994 ! Addison-Wesley Longman, Inc. ! Fundamentals of Database Systems !3rd Edition Ramez --- 78,107 ! An Introduction to Database Systems ! Date, 2004 ! Eighth Edition C. J. Date ! 0-321-19784-4 ! 2003 Addison-Wesley ! 2004 ! Pearson Education, Inc. ! Fundamentals of Database Systems !Fourth Edition Ramez *** *** 113,123 Navathe !0-805-31755-4 !August 1999 Addison-Wesley --- 112,125 Navathe !0-321-12226-7 !2003 Addison-Wesley + + 2004 + Index: doc/src/sgml/geqo.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/geqo.sgml,v retrieving revision 1.28 diff -c -r1.28 geqo.sgml *** doc/src/sgml/geqo.sgml 22 Jan 2005 22:56:36 - 1.28 --- doc/src/sgml/geqo.sgml 20 Feb 2005 18:02:24 - *** *** 302,308 ! --- 302,308 ! Index: doc/src/sgml/sql.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/sql.sgml,v retrieving revision 1.34 diff -c -r1.34 sql.sgml *** doc/src/sgml/sql.sgml 22 Jan 2005 22:56:36 - 1.34 --- doc/src/sgml/sql.sgml 20 Feb 2005 18:02:25 - *** *** 647,653 For a more detailed description and definition of the relational algebra refer to [] or ! []. --- 647,653 For a more detailed description and definition of the relational algebra refer to [] or ! []. *** *** 714,720 the one underlying the most relational languages. For a detailed discussion on DRC (and also TRC) see ! or . --- 714,720 the one underlying the most relational languages. For a detailed discussion on DRC (and also TRC) see ! or . *** *** 772,778 algorithm) by which an arbitrary expression of the relational calculus can be reduced to a semantically equivalent expression of relational algebra. For a more detailed discussion on that refer to ! and . --- 772,778 algorithm) by which an arbitrary expression of the relational calculus can be reduced to a semantically equivalent expression of relational algebra. For a more detailed discussion on that refer to ! and . *** *** 2076,2082 for a more detailed description). For more information about system c
Re: [PATCHES] Patch for disaster recovery
On Sun, Feb 20, 2005 at 09:43:11 -0500, Bruce Momjian wrote: > > We regularly have people on IRC who delete data and then want to recover > it. By having the define it makes it easier for us to help them without > them having to add actual C code. > > Does that make sense? You aren't going to get a consistant snapshot if you get back all of the deleted rows. With autovacuum it is going to get harder to do this, because accidentally making large changes in a table is going to trigger a vacuum. It seems like the right way to do this is a recovery using the PITR system and putting effort into making that easier is the way to go. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Patch for disaster recovery
Tom Lane wrote: > Not sure where this leads to, but it's not leading to an undocumented > one-line hack in tqual.c, and definitely not *that* one-line hack. Sorry, here is the proper change I just applied: /* This is to be used only for disaster recovery and requires serious analysis. */ #ifndef MAKE_ALL_TUPLES_VISIBLE return false; #else return true; #endif -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: [PATCHES] Patch for disaster recovery
Tom Lane wrote:
> Not sure where this leads to, but it's not leading to an undocumented
> one-line hack in tqual.c, and definitely not *that* one-line hack.
OK, it turns out the bottom of the function is the right place to fix
this. Patch attached and applied.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/utils/time/tqual.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/time/tqual.c,v
retrieving revision 1.82
diff -c -c -r1.82 tqual.c
*** src/backend/utils/time/tqual.c 20 Feb 2005 04:56:00 - 1.82
--- src/backend/utils/time/tqual.c 20 Feb 2005 14:56:33 -
***
*** 776,786
HeapTupleSatisfiesSnapshot(HeapTupleHeader tuple, Snapshot snapshot,
Buffer buffer)
{
- /* This is to be used only for disaster recovery and requires serious
analysis. */
- #ifdef MAKE_ALL_TUPLES_VISIBLE
- return true;
- #endif
-
if (!(tuple->t_infomask & HEAP_XMIN_COMMITTED))
{
if (tuple->t_infomask & HEAP_XMIN_INVALID)
--- 776,781
***
*** 965,971
--- 960,971
}
}
+ /* This is to be used only for disaster recovery and requires serious
analysis. */
+ #ifdef MAKE_ALL_TUPLES_VISIBLE
return false;
+ #else
+ return true;
+ #endif
}
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] Patch for disaster recovery
Tom Lane wrote: > Bruce Momjian writes: > > + /* This is to be used only for disaster recovery and requires serious > > analysis. */ > > + #ifdef MAKE_ALL_TUPLES_VISIBLE > > + return true; > > + #endif > > If this requires serious analysis, why did you install the patch without > any public discussion? > > I cannot imagine any situation where this wouldn't break things beyond > belief, and so I request that you revert the patch until you've provided > a real example in which it would help. We regularly have people on IRC who delete data and then want to recover it. By having the define it makes it easier for us to help them without them having to add actual C code. Does that make sense? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: [PATCHES] Patch for disaster recovery
Tom Lane wrote: > Michael Fuhr <[EMAIL PROTECTED]> writes: > > Hmmm...after seeing Tom's reply, I suppose I should have first > > asked, "Gee, looks simple, but does it work?" Should I even bother > > experimenting with it in a test environment? > > Experiment away, but I have a hard time visualizing how you'll find it > useful. > > Just brainstorming here, but it seems to me that what might make some > kind of sense is a command to "undelete all tuples in this table". > You do that, you look through them, you delete the versions you don't > want, you're happy. The problem with the patch as-is is that (a) > "deleting the versions you don't want" is a no-op, so you cannot keep > straight what you've done in terms of filtering out garbage; and (b) > when you revert to a non-broken postmaster, the stuff you couldn't see > before goes back to being unseeable, because after all you didn't change > its state. It would be used only for dumping the table out and reverting to the regular postmaster. > With either the snapshot kluge or the undelete-all kluge, you have an > issue in that constraints are broken wholesale --- you can see lots of > duplicate row versions that violate unique constraints, deleted versions > that violate FK constraints because they reference also-deleted master > rows, deleted versions that violate later-added CHECK constraints, etc. > I'd sort of like to see the system flip into some mode that says "we're > not promising constraints are honored", and then you can't go back to > normal operation without going through some pushup that checks all the > remaining rows satisfy the declared constraints. > > In any case I suspect it's a bad idea to treat tuples as good if their > originating transaction did not commit. For starters, such a tuple > might not possess all the index entries it should (if the originating > transaction failed before inserting said entries). I think what we > want to think about is overriding delete commands, not overriding > insert failures. > > Not sure where this leads to, but it's not leading to an undocumented > one-line hack in tqual.c, and definitely not *that* one-line hack. Yea, it should be more precise about showing only delete stuff and not uncommitted creates. Let me work on that. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: [PATCHES] Patch for disaster recovery
On Sun, Feb 20, 2005 at 02:21:00AM -0500, Tom Lane wrote: > Just brainstorming here, but it seems to me that what might make some > kind of sense is a command to "undelete all tuples in this table". Would it be possible to start a transaction with specific snapshot parameters? Could you "time warp" that way, assuming that what you're looking for hasn't already been vacuumed away? Rather than modifying anything, you'd SELECT or COPY the data somewhere and then restore it when you came "back to the future." Just another brainstorm...certainly not thought very far through yet. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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
