Re: [HACKERS] Postgresql likes Tuesday...
On Mon, Sep 30, 2002 at 06:31:15PM -0400, Tom Lane wrote:
The middle part of that boils down (as of today) to
regression=# select to_date('402002', 'WW');
to_date
2002-10-01
(1 row)
and Oct 1 (tomorrow) is Tuesday. As to why it picks that day to
represent Week 40 of 2002, it's probably related to the fact that Week 1
of 2002 is converted to
regression=# select to_date('012002', 'WW');
to_date
2002-01-01
(1 row)
which was a Tuesday.
Offhand this seems kinda inconsistent to me --- I'd expect
regression=# select extract(week from date '2002-09-30');
date_part
---
40
(1 row)
to produce 39, not 40, on the grounds that the first day of Week 40
is tomorrow not today. Alternatively, if today is the first day of
Week 40 (as EXTRACT(week) seems to think), then ISTM that the to_date
expression should produce today not tomorrow.
I notice that 2001-12-31 is considered part of the first week of 2002,
which is also pretty surprising:
regression=# select extract(week from date '2001-12-31');
date_part
---
1
(1 row)
Anyone able to check this stuff on Oracle? What exactly are the
boundary points for EXTRACT(week), and does to_date() agree?
Please, read docs -- to_() functions know two versions of number of
week
IW = iso-week
WW = oracle week
test=# select to_date('402002', 'WW');
to_date
2002-10-01
(1 row)
test=# select to_date('402002', 'IW');
to_date
2002-09-30
(1 row)
test=# select to_date('012002', 'WW');
to_date
2002-01-01
(1 row)
test=# select to_date('012002', 'IW');
to_date
2001-12-31
(1 row)
Karel
--
Karel Zak [EMAIL PROTECTED]
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psqlODBC *nix Makefile (new 7.3 open item?)
-Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] Sent: 30 September 2002 21:11 To: Dave Page Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [HACKERS] psqlODBC *nix Makefile (new 7.3 open item?) Dave Page writes: Can someone who knows make better than I (which is probably the vast majority of you!) knock up a makefile so the driver will build standalone on *nix systems please? There should be no dependencies on any of the rest of the code - certainly there isn't for the Win32 build. I'm working something out. I'll send it to you tomorrow. Thanks Peter. ---(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] Postgresql likes Tuesday...
On Mon, Sep 30, 2002 at 05:37:47PM -0400, Rod Taylor wrote:
select to_char(
to_date(
CAST(extract(week from CURRENT_TIMESTAMP) as text)
|| CAST(extract(year from CURRENT_TIMESTAMP) as text)
, 'WW')
, 'FMDay, D');
to_char
Tuesday, 3
(1 row)
The PostgreSQL not loves Thuesday, but WW for year 2002 loves it. Why?
Because 'WW' = (day_of_year - 1) / 7 + 1, other words this year
start on Thuesday (see 01-JAN-2002) and WW start weeks each 7 days
after this first day of year.
If you need human week you must use IW (iso-week) that start every
Monday.
I know there're countries where week start on Sunday, but it's not supported
-- the problem is with 'D' it returns day-of-week for Sunday-based-week.
Your example (I use to_xxx () only, it's more readable):
If you need correct for Sunday-based-week:
select to_char( to_date(to_char(now(), 'IW'), 'IW')-'1d'::interval, 'FMDay,
D');
to_char
---
Sunday, 1
If you need Monday-based-week (ISO week):
test=# select to_char( to_date(to_char(now(), 'IW'), 'IW'), 'FMDay, D');
to_char
---
Monday, 2
'2' is problem -- maybe add to to_xxx() functions 'ID' as day-of-isoweek.
It's really small change I think we can do it for 7.3 too.
What think about it our Toms?
In the Oracle it's same (means WW vs. IW vs. D)
SVRMGR select to_char(to_date('30-SEP-02'), 'WW IW Day D') from dual;
TO_CHAR(TO_DATE('
-
39 40 Monday2
test=# select to_char('30-SEP-02'::date, 'WW IW Day D');
to_char
---
39 40 Monday2
SVRMGR select to_char(to_date('29-SEP-02'), 'WW IW Day D') from dual;
TO_CHAR(TO_DATE('
-
39 39 Sunday1
test=# select to_char('29-SEP-02'::date, 'WW IW Day D');
to_char
---
39 39 Sunday1
Karel
--
Karel Zak [EMAIL PROTECTED]
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.2.3 patching done
Hello! BTW, is it possible to have just patch against previous version (to reduce traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz? -- WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group. Phone: +7 (3832) 106228, ext.140, E-mail: [EMAIL PROTECTED] Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. ---(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: AIX compilation problems (was Re: [HACKERS] Proposal ...)
Attached is a patch to fix the mb linking problems on AIX. As a nice side effect it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so (all shlibs that are not postmaster loadable modules). Can you explain the method behind your patch? Have you tried -bnogc? -bnogc would (probably) have been the correct switch reading the man page, but the method was previously not good since it involved the following: 1. create a static postgres executable from the SUBSYS.o's 2. create an exports file from above 3. recreate a shared postgres executable This naturally had a cyclic dependency, that could not properly be reflected in the Makefile (thus a second make sometimes left you with a static postgres unless you manually removed postgres.imp). Now it does: postgres.imp: $(OBJS) create a temporary SUBSYS.o from all $(OBJS) create a postgres.imp from SUBSYS.o rm temporary SUBSYS.o postgres: postgres.imp link a shared postgres A second change was to move the import and export files to the end of the link line, then the linker knows not to throw a duplicate symbol warning, and keeps all symbols that are mentioned in the exports file (== -bnogc restricted to $(OBJS) symbols). Thus now only libpq.so and libecpg.so still show the duplicate symbol warnings since their link line should actually not include postgres.imp . I did not see how to make a difference between loadable modules (need postgres.imp) and interface libraries (do not need postgres.imp), but since the resulting libs are ok, I left it at that. I tested both gcc and xlc including regression tests. 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
[HACKERS] pg_dump and large files - is this a problem?
Is it my imagination, or is there a problem with the way pg_dump uses off_t etc. My understanding is that off_t may be 64 bits on systems with 32 bit ints. But it looks like pg_dump writes them as 4 byte values in all cases. It also reads them as 4 byte values. Does this seem like a problem to anybody else? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /() __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Postgresql likes Tuesday...
Karel Zak [EMAIL PROTECTED] writes: What think about it our Toms? ... In the Oracle it's same (means WW vs. IW vs. D) If it works the same as Oracle then I'm happy with it; that's what it's supposed to do. The real point here seems to be that EXTRACT(week) corresponds to to_date's IW conversion, not WW conversion. This is indeed implied by the docs, but it's not stated plainly (there's just a reference to ISO in each of the relevant pages). Perhaps we need more documentation, or a different layout that would offer a place to put notes like this one. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump and large files - is this a problem?
Philip Warner [EMAIL PROTECTED] writes: Is it my imagination, or is there a problem with the way pg_dump uses off_t etc. My understanding is that off_t may be 64 bits on systems with 32 bit ints. But it looks like pg_dump writes them as 4 byte values in all cases. It also reads them as 4 byte values. Does this seem like a problem to anybody else? Yes, it does --- the implication is that the custom format, at least, can't support dumps 4Gb. What exactly is pg_dump writing off_t's into files for; maybe there's not really a problem? If there is a problem, seems like we'd better fix it. Perhaps there needs to be something in the header to tell the reader the sizeof off_t. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] floor function in 7.3b2
I noticed that some of my queries don't work anymore because they're using
the floor function:
e.g.: select type, floor(date_part('epoch', dataend)) as ts from
last_modified
Why is floor not working anymore? I guess I can use round too, but I don't
want to modify semantics.
Regards,
Mario Weilguni
icomedias communication solutions/graz . berlin
---
icomedias ist Hersteller von icocms: Information-
und Content Management System für Inter- UND INTRAnet
---
Mario Weilguni icomedias gmbh
software engineering entenplatz 1
tel: +43-316-721.671-178020 graz, austria
fax: +43-316-721.671-26http://www.icomedias.com
e-mail: [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] floor function in 7.3b2
Mario Weilguni [EMAIL PROTECTED] writes:
I noticed that some of my queries don't work anymore because they're using
the floor function:
e.g.: select type, floor(date_part('epoch', dataend)) as ts from
last_modified
Why is floor not working anymore?
Mph. Seems we have floor(numeric) but not floor(float8), and the latter
is what you need here.
You could cast date_part's result to numeric; or perhaps you could use
trunc() which exists in both numeric and float8 flavors. It's got
different semantics for negative inputs though.
For 7.4 we should take another look at the operator/function set and
fill in this hole and any others like it.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Postgresql likes Tuesday...
If it's of any use the following link gives some info on different schemes and details on an ISO week numbering standard. http://www.merlyn.demon.co.uk/weekinfo.htm#WkNo Best Regards, Tim Knowles ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql/contrib/rserv ApplySnapshot.in CleanLog.
Alexey V. Borzov writes: Agh! I finally read up on module loading http://developer.postgresql.org/docs/postgres/xfunc-c.html#XFUNC-C-DYNLOAD and now I seem to understand. You see, the problem with the current Makefile is as follows: it substitutes '$libdir' into both .sql and perl files. While this is good enough for sql, $libdir is consumed by Perl and thus perl scripts do NOT work. Then fix the Perl scripts. Keep the bizarre code close to the cause, so it's easier to maintain. -- Peter Eisentraut [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] pg_dump and large files - is this a problem?
Tom Lane writes: Yes, it does --- the implication is that the custom format, at least, can't support dumps 4Gb. What exactly is pg_dump writing off_t's into files for; maybe there's not really a problem? That's kind of what I was wondering, too. Not that it's an excuse, but I think that large file access through zlib won't work anyway. Zlib uses the integer types in fairly random ways. -- 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])
[HACKERS] table lock and record lock
what's the default lock in pgsql? if I issued insert(copy)/or update processed on the same table but on different records the same time, how those processes will affect each other? thanks. johnl ---(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] table lock and record lock
On Tue, Oct 01, 2002 at 03:30:38PM -0500, John Liu wrote: what's the default lock in pgsql? if I issued insert(copy)/or update processed on the same table but on different records the same time, how those processes will affect each other? You might want to check out the docs at http://developer.postgresql.org/docs/pgsql/src/tools/backend/index.html and http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/mvcc.html to learn the answers to these questions. There's no general answer to your question, exactly, since you talk about insert, copy, and update. A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Purpose of rscale/dscale in NUMERIC?
What is the reason for maintaining separate rscale and dscale values in numeric variables? I am finding that this arrangement leads to some odd results, for example this: regression=# select (exp(ln(2.0)) - 2.0); ?column? - -0. (1 row) regression=# select (exp(ln(2.0)) - 2.0) * 10; ?column? - -0.0010 (1 row) The difference between rscale and dscale allows some hidden digits to be carried along in an expression result, and then possibly exposed later. This seems pretty nonintuitive for an allegedly exact calculational datatype. ISTM the policy should be what you see is what you get - no hidden digits. That would mean there's no need for separating rscale and dscale, so I'm wondering why they were put in to begin with. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] table lock and record lock
On Tue, 1 Oct 2002, John Liu wrote: what's the default lock in pgsql? if I issued insert(copy)/or update processed on the same table but on different records the same time, how those processes will affect each other? postgresql does not do locking in the sense of how most database do locking. It uses a system called multi-version concurrency control that prevents writers from blocking readers and vice versa. It has advantages and disadvantages over the row locking methodology used by most other databases, but you can read for yourself by looking in the docs at: http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/mvcc.html Good luck. ---(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] pg_dump and large files - is this a problem?
At 09:59 AM 1/10/2002 -0400, Tom Lane wrote: If there is a problem, seems like we'd better fix it. Perhaps there needs to be something in the header to tell the reader the sizeof off_t. Yes, and do the peripheral stuff to support old archives etc. We also need to be careful about the places where we do file-position-arithmetic - if there are any, I can't recall. I am not sure we need to worry about whether zlib supports large files since I am pretty sure we don't use zlib for file IO - we just pass it in-memory blocks; so it should work no matter how much data is in the stream. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /() __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] some more minor incompatibilties 7.2 - 7.3
I noticed some other minor differences between 7.2 and 7.3: * 7.2: select now() + '1 minute'::timespan = works * 7.2: select now() + '1 minute'::reltime = works * 7.3: select now() + '1 minute'::timespan = does not work (Type timespan does not exist) * 7.3 select now() + '1 minute'::reltime = works So timespan is no longer supported I guess, but reltime will work as well. Is there a compatibility or migration section in the documentation that might help users to handle this? Maybe we can collect such reports and prepare a upgrade tutorial? Regards, Mario ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.2.3 patching done
Yury Bokhoncovich wrote: Hello! BTW, is it possible to have just patch against previous version (to reduce traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz? In some releases, it is possible, in others we add/remove files and it isn't possible. I think because it isn't always possible we normally don't do it. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2.3 patching done
Hello! On Tue, 1 Oct 2002, Bruce Momjian wrote: In some releases, it is possible, in others we add/remove files and it isn't possible. I think because it isn't always possible we normally don't do it. I think it's enough to do diffs for minor release (i.e. 7.2.2-7.2.3, 7.3.0-7.3.1 and so on). BTW, I had no problems with patching Linux kernel this way (e.g. having vanilla 2.2.16 then sequentially patch for 2.2.17, .18, .19, .20, .21, .22) though there were added directories. -- WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group. Phone: +7 (3832) 106228, ext.140, E-mail: [EMAIL PROTECTED] Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump and large files - is this a problem?
Tom Lane wrote: Philip Warner [EMAIL PROTECTED] writes: Is it my imagination, or is there a problem with the way pg_dump uses off_t etc. My understanding is that off_t may be 64 bits on systems with 32 bit ints. But it looks like pg_dump writes them as 4 byte values in all cases. It also reads them as 4 byte values. Does this seem like a problem to anybody else? Yes, it does --- the implication is that the custom format, at least, can't support dumps 4Gb. What exactly is pg_dump writing off_t's into files for; maybe there's not really a problem? If there is a problem, seems like we'd better fix it. Perhaps there needs to be something in the header to tell the reader the sizeof off_t. BSD/OS has 64-bit off_t's so it does support large files. Is there something I can test? -- 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]
Re: [HACKERS] 7.2.3 patching done
Bruce Momjian writes: BTW, is it possible to have just patch against previous version (to reduce traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz? In some releases, it is possible, in others we add/remove files and it isn't possible. I think because it isn't always possible we normally don't do it. Adding or removing files isn't the problem (see -N option). Binary files are the problem. Using xdelta would be safe, though. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psqlODBC *nix Makefile (new 7.3 open item?)
Dave Page writes: majority of you!) knock up a makefile so the driver will build standalone on *nix systems please? There should be no dependencies on any of the rest of the code - certainly there isn't for the Win32 build. I'm working something out. I'll send it to you tomorrow. Hah. I tried to put something together based on Automake and Libtool, but I must conclude that Libtool is just completely utterly broken. I also considered copying over Makefile.shlib, but that would draw in too many auxiliary files and create a different kind of mess. So what I would suggest right now as the course of action is to copy your local psqlodbc subtree to its old location under interfaces/ and try to hook things together that way. Perhaps one of these days we should convert Makefile.shlib into a shell script that we can deploy more easily to different projects. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.2.3 patching done
Peter Eisentraut wrote: Bruce Momjian writes: BTW, is it possible to have just patch against previous version (to reduce traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz? In some releases, it is possible, in others we add/remove files and it isn't possible. I think because it isn't always possible we normally don't do it. Adding or removing files isn't the problem (see -N option). Binary files are the problem. Do we change any binary files in minor releases, or even major ones? -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2.3 patching done
Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: Adding or removing files isn't the problem (see -N option). Binary files are the problem. Do we change any binary files in minor releases, or even major ones? But the source distribution hasn't *got* any binary files. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2.3 patching done
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: Adding or removing files isn't the problem (see -N option). Binary files are the problem. Do we change any binary files in minor releases, or even major ones? But the source distribution hasn't *got* any binary files. Yea, that was sort of my point. -- 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/users-lounge/docs/faq.html
[HACKERS] New PostgreSQL Website : advocacy.postgresql.org
Hi all, Over the last few weeks we've put together a new Advocacy and Marketing website for PostgreSQL: http://advocacy.postgresql.org It's now ready for public release. It has the first few case studies, lists the major advantages to PostgreSQL, and provides a place you can point your CIO, CTO, and CEO's at, etc. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump and large files - is this a problem?
At 11:20 AM 1/10/2002 -0400, Bruce Momjian wrote: BSD/OS has 64-bit off_t's so it does support large files. Is there something I can test? Not really since it saves only the first 32 bits of the 64 bit positions it will do no worse than a version that supports 32 bits only. It might even do slightly better. When this is sorted out, we need to verify that: - large dump files are restorable - dump files with 32 bit off_t restore properly on systems with 64 biy off_t - dump files with 64 bit off_t restore properly on systems with 32 bit off_tAS LONG AS the offsets are less than 32 bits. - old dump files restore properly. - new dump files have a new version number so that old pg_restore will not try to restore them. We probably need to add Read/WriteOffset to pg_backup_archiver.c to read the appropriate sized value from a dump file, in the same way that Read/WriteInt works now. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /() __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
