Re: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Jan Wieck wrote: > >> When was char() fixed size? > > > char() was fixed size only in that you could cache the column offsets > > for char() becuase it was always the same width on disk before TOAST. > > But that was already broken by MULTIBYTE. Yes, I think there was conditional code that had the optimization only for non-multibyte servers. Of course, now multibyte is default. -- 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: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
Bruce Momjian <[EMAIL PROTECTED]> writes: > Jan Wieck wrote: >> When was char() fixed size? > char() was fixed size only in that you could cache the column offsets > for char() becuase it was always the same width on disk before TOAST. But that was already broken by MULTIBYTE. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
Jan Wieck wrote: > Bruce Momjian wrote: > > > > Alessio Bragadini wrote: > > > On Sat, 2002-10-12 at 11:37, Gavin Sherry wrote: > > > > > > > I cannot think of any reason why changing column order should be > > > > implemented in Postgres. Seems like a waste of time/more code bloat for > > > > something which is strictly asthetic. > > > > > > > > Regardless, I do have collegues/clients who ask when such a feature will > > > > be implemented. Why is this useful? > > > > > > Has column ordering any effect on the physical tuple disposition? I've > > > heard discussions about keeping fixed-size fields at the beginning of > > > the tuple and similar. > > > > > > Sorry for the lame question. :-) > > > > Yes, column ordering matches physical column ordering in the file, and > > yes, there is a small penalty for accessing any columns after the first > > variable-length column (pg_type.typlen < 0). CHAR() used to be a fixed > > length column, but with TOAST (large offline storage) it became variable > > length too. I don't think there is much of a performance hit, though. > > When was char() fixed size? We had fixed size things like char, char2, > char4 ... char16. But char() is internally bpchar() and has allways been > variable-length. char() was fixed size only in that you could cache the column offsets for char() becuase it was always the same width on disk before TOAST. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
Bruce Momjian wrote: > > Alessio Bragadini wrote: > > On Sat, 2002-10-12 at 11:37, Gavin Sherry wrote: > > > > > I cannot think of any reason why changing column order should be > > > implemented in Postgres. Seems like a waste of time/more code bloat for > > > something which is strictly asthetic. > > > > > > Regardless, I do have collegues/clients who ask when such a feature will > > > be implemented. Why is this useful? > > > > Has column ordering any effect on the physical tuple disposition? I've > > heard discussions about keeping fixed-size fields at the beginning of > > the tuple and similar. > > > > Sorry for the lame question. :-) > > Yes, column ordering matches physical column ordering in the file, and > yes, there is a small penalty for accessing any columns after the first > variable-length column (pg_type.typlen < 0). CHAR() used to be a fixed > length column, but with TOAST (large offline storage) it became variable > length too. I don't think there is much of a performance hit, though. When was char() fixed size? We had fixed size things like char, char2, char4 ... char16. But char() is internally bpchar() and has allways been variable-length. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
On Mon, Oct 14, 2002 at 11:04:07AM -0400, Bruce Momjian wrote: > Alessio Bragadini wrote: > > On Sat, 2002-10-12 at 11:37, Gavin Sherry wrote: > > > > > I cannot think of any reason why changing column order should be > > > implemented in Postgres. Seems like a waste of time/more code bloat for > > > something which is strictly asthetic. > > > > Has column ordering any effect on the physical tuple disposition? I've > > heard discussions about keeping fixed-size fields at the beginning of > > the tuple and similar. > > Yes, column ordering matches physical column ordering in the file, and > yes, there is a small penalty for accessing any columns after the first > variable-length column (pg_type.typlen < 0). And note that if column ordering was to be implemented through the use of attlognum or something similar, the physical ordering would not be affected. The only way to physically reoder the columns would be to completely rebuild the table. -- Alvaro Herrera () "Aprende a avergonzarte mas ante ti que ante los demas" (Democrito) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
Alessio Bragadini wrote: > On Sat, 2002-10-12 at 11:37, Gavin Sherry wrote: > > > I cannot think of any reason why changing column order should be > > implemented in Postgres. Seems like a waste of time/more code bloat for > > something which is strictly asthetic. > > > > Regardless, I do have collegues/clients who ask when such a feature will > > be implemented. Why is this useful? > > Has column ordering any effect on the physical tuple disposition? I've > heard discussions about keeping fixed-size fields at the beginning of > the tuple and similar. > > Sorry for the lame question. :-) Yes, column ordering matches physical column ordering in the file, and yes, there is a small penalty for accessing any columns after the first variable-length column (pg_type.typlen < 0). CHAR() used to be a fixed length column, but with TOAST (large offline storage) it became variable length too. I don't think there is much of a performance hit, though. -- 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: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
On Sat, 2002-10-12 at 11:37, Gavin Sherry wrote: > I cannot think of any reason why changing column order should be > implemented in Postgres. Seems like a waste of time/more code bloat for > something which is strictly asthetic. > > Regardless, I do have collegues/clients who ask when such a feature will > be implemented. Why is this useful? Has column ordering any effect on the physical tuple disposition? I've heard discussions about keeping fixed-size fields at the beginning of the tuple and similar. Sorry for the lame question. :-) -- Alessio F. Bragadini[EMAIL PROTECTED] APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-22-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
On Sat, Oct 12, 2002 at 12:43:37 +0300, Antti Haapala <[EMAIL PROTECTED]> wrote: > > > I cannot think of any reason why changing column order should be > > implemented in Postgres. Seems like a waste of time/more code bloat for > > something which is strictly asthetic. > > What about copy? AFAIK, copy doesn't allow column names being specified, > so it's not purely aesthetic... The SQL COPY command does (at least in 7.3). The \copy psql command doesn't seem to allow this though. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] MySQL vs PostgreSQL.
Hannu Krosing wrote: > Alvaro Herrera kirjutas L, 12.10.2002 kell 04:16: > > On Fri, Oct 11, 2002 at 07:08:18PM -0700, Jeff Davis wrote: > > > > > And it really is a minor matter of convenience. I end up dropping and > > > recreating all my tables a lot in the early stages of development, which is > > > mildly annoying. Certainly not as bad, I suppose, as if you're led to believe > > > that a feature does something safely, and it kills all your data. > > > > Now that ALTER TABLE DROP COLUMN is implemented, there probably isn't > > any more the need to do such frequent drop/create of tables. > > Did attlognum's (for changing column order) get implemented for 7.2 ? No, changing column order isn't even on the TODO list. -- 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: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
On 12 Oct 2002 at 2:54, Jeff Davis wrote: > As far as I can tell, the order the attributes are returned makes no > difference in a client application, unless you're referencing attributes by > number. All applications that I've made or seen all use the name instead, and > I've never heard otherwise, or heard any advantage to using numbers to > reference columns. Even in that case you can obtain field number for a given name and vise versa.. > When someone asks, ask them "why?". I'd be interested to know if they have > some other reason. I would think that if they absolutely wanted to fine-tune > the order of columns they'd use a view (seems a little easier than > continually changing order around by individual SQL statements). Sounds fine but what is about that "continually changing"? A view needs a change only if it alters fields selected/tables to select from/selection criteria. Field order does not figure in there.. Bye Shridhar -- QOTD: "A child of 5 could understand this! Fetch me a child of 5." ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
On 12 Oct 2002, Hannu Krosing wrote: > Alvaro Herrera kirjutas L, 12.10.2002 kell 04:16: > > On Fri, Oct 11, 2002 at 07:08:18PM -0700, Jeff Davis wrote: > > > > > And it really is a minor matter of convenience. I end up dropping and > > > recreating all my tables a lot in the early stages of development, which is > > > mildly annoying. Certainly not as bad, I suppose, as if you're led to believe > > > that a feature does something safely, and it kills all your data. > > > > Now that ALTER TABLE DROP COLUMN is implemented, there probably isn't > > any more the need to do such frequent drop/create of tables. > > Did attlognum's (for changing column order) get implemented for 7.2 ? I cannot think of any reason why changing column order should be implemented in Postgres. Seems like a waste of time/more code bloat for something which is strictly asthetic. Regardless, I do have collegues/clients who ask when such a feature will be implemented. Why is this useful? Gavin ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
> > > > Did attlognum's (for changing column order) get implemented for 7.2 ? > > I cannot think of any reason why changing column order should be > implemented in Postgres. Seems like a waste of time/more code bloat for > something which is strictly asthetic. > > Regardless, I do have collegues/clients who ask when such a feature will > be implemented. Why is this useful? > I think even "asthetic" might go too far. It seems mostly irrelevent except for people who are obsessive compulsive and operate in interactive psql a lot. It's marginally simpler to get the columns ordered the way you want so that you can just do "SELECT * ..." rather than "SELECT att0,att1,... ..." at the interactive psql prompt, and still get the columns in your favorite order. As far as I can tell, the order the attributes are returned makes no difference in a client application, unless you're referencing attributes by number. All applications that I've made or seen all use the name instead, and I've never heard otherwise, or heard any advantage to using numbers to reference columns. When someone asks, ask them "why?". I'd be interested to know if they have some other reason. I would think that if they absolutely wanted to fine-tune the order of columns they'd use a view (seems a little easier than continually changing order around by individual SQL statements). Regards, Jeff ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Changing Column Order (Was Re: [HACKERS] MySQL vs PostgreSQL.)
> I cannot think of any reason why changing column order should be > implemented in Postgres. Seems like a waste of time/more code bloat for > something which is strictly asthetic. What about copy? AFAIK, copy doesn't allow column names being specified, so it's not purely aesthetic... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] MySQL vs PostgreSQL.
Alvaro Herrera kirjutas L, 12.10.2002 kell 04:16: > On Fri, Oct 11, 2002 at 07:08:18PM -0700, Jeff Davis wrote: > > > And it really is a minor matter of convenience. I end up dropping and > > recreating all my tables a lot in the early stages of development, which is > > mildly annoying. Certainly not as bad, I suppose, as if you're led to believe > > that a feature does something safely, and it kills all your data. > > Now that ALTER TABLE DROP COLUMN is implemented, there probably isn't > any more the need to do such frequent drop/create of tables. Did attlognum's (for changing column order) get implemented for 7.2 ? Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] MySQL vs PostgreSQL.
Oh yes, I agree. ALTER TABLE ... DROP COLUMN helps out a lot. I actually don't use that for much yet because 7.3 is still in beta. However, I certainly can't complain to the developers for it since it's already developed :) I am consistantly amazed by every minor version release. If postgres had a marketing team it would be at version 37.3 by now. In my last email I agreed with Scott Marlowe that postgres is better off without the casting of an entire column, since that's kind of a dangeous procedure and can be completed in a round-about (read: explicit) way by postgres anyway, that doesn't lose your data until after you've had a chance to look at the new stuff. Regards, Jeff On Friday 11 October 2002 07:16 pm, you wrote: > On Fri, Oct 11, 2002 at 07:08:18PM -0700, Jeff Davis wrote: > > And it really is a minor matter of convenience. I end up dropping and > > recreating all my tables a lot in the early stages of development, which > > is mildly annoying. Certainly not as bad, I suppose, as if you're led to > > believe that a feature does something safely, and it kills all your data. > > Now that ALTER TABLE DROP COLUMN is implemented, there probably isn't > any more the need to do such frequent drop/create of tables. > > And things just keep getting better and better. This is really amazing. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] MySQL vs PostgreSQL.
On Fri, Oct 11, 2002 at 07:08:18PM -0700, Jeff Davis wrote: > And it really is a minor matter of convenience. I end up dropping and > recreating all my tables a lot in the early stages of development, which is > mildly annoying. Certainly not as bad, I suppose, as if you're led to believe > that a feature does something safely, and it kills all your data. Now that ALTER TABLE DROP COLUMN is implemented, there probably isn't any more the need to do such frequent drop/create of tables. And things just keep getting better and better. This is really amazing. -- Alvaro Herrera () "We are who we choose to be", sang the goldfinch when the sun is high (Sandman) ---(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] MySQL vs PostgreSQL.
> > I still remember a post from somebody on the phpbuilder site that had > changed a field from varchar to date and all the dates he had got changed > to -00-00. > > He most unimpressed, especially since he (being typical of a lot of MySQL > users) didn't have a backup. > Ah, yes. Classic. I was talking about a development scenario. Anyone who changes a huge amount of important data to a new form without a clearly defined algorithm is not making a wise choice. That's kind of like if you have a perl script operating on an important file: you don't want it to just kill all your data, so you do a few tests first. And it really is a minor matter of convenience. I end up dropping and recreating all my tables a lot in the early stages of development, which is mildly annoying. Certainly not as bad, I suppose, as if you're led to believe that a feature does something safely, and it kills all your data. So, you're right. It's probably better that it's never implemented. Regards, Jeff ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] MySQL vs PostgreSQL.
scott.marlowe wrote: On Fri, 11 Oct 2002, Jeff Davis wrote: I agree with your message except for that statement. MySQL alter table provides the ability to change column types and cast the records automatically. I remember that feature as really the only thing from MySQL that I've ever missed. Of course, it's not that wonderful in theory. During development you can easily drop/recreate the tables and reload the test data; during production you don't change the data types of your attributes. But in practice, during development it's handy sometimes. I still remember a post from somebody on the phpbuilder site that had changed a field from varchar to date and all the dates he had got changed to -00-00. He most unimpressed, especially since he (being typical of a lot of MySQL users) didn't have a backup. Couldn't he just do ROLLBACK? ;-) (for the humor impaired, that's a joke...) Mike Mascari [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] MySQL vs PostgreSQL.
> They also state that they have more sophisticated ALTER TABLE... > > Only usable feature in their ALTER TABLE that doesn't (yet) exist in > PostgreSQL was changing column order (ok, the order by in table creation > could be nice), and that's still almost purely cosmetic. Anyway, I could > have used that command yesterday. Could this be added to pgsql. > I agree with your message except for that statement. MySQL alter table provides the ability to change column types and cast the records automatically. I remember that feature as really the only thing from MySQL that I've ever missed. Of course, it's not that wonderful in theory. During development you can easily drop/recreate the tables and reload the test data; during production you don't change the data types of your attributes. But in practice, during development it's handy sometimes. Regards, Jeff ---(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] MySQL vs PostgreSQL.
On Fri, 11 Oct 2002, Jeff Davis wrote: > > They also state that they have more sophisticated ALTER TABLE... > > > > Only usable feature in their ALTER TABLE that doesn't (yet) exist in > > PostgreSQL was changing column order (ok, the order by in table creation > > could be nice), and that's still almost purely cosmetic. Anyway, I could > > have used that command yesterday. Could this be added to pgsql. > > > > I agree with your message except for that statement. MySQL alter table > provides the ability to change column types and cast the records > automatically. I remember that feature as really the only thing from MySQL > that I've ever missed. > > Of course, it's not that wonderful in theory. During development you can > easily drop/recreate the tables and reload the test data; during production > you don't change the data types of your attributes. > > But in practice, during development it's handy sometimes. I still remember a post from somebody on the phpbuilder site that had changed a field from varchar to date and all the dates he had got changed to -00-00. He most unimpressed, especially since he (being typical of a lot of MySQL users) didn't have a backup. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] MySQL vs PostgreSQL.
Rod Taylor wrote: > > On Fri, 2002-10-11 at 09:20, Antti Haapala wrote: > > > > Check out: > > > > http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html > > > > MySQL AB compares MySQL with PostgreSQL. > > I wouldn't look too far into these at all. I've tried to get > ' " as identifier quote (ANSI SQL) ' corrected on the crash-me pages for > us a couple of times (they say we don't support it for some reason). It's once again the typical MySQL propaganda. As usual they compare a future version of MySQL against an old release of PostgreSQL. And they just compare on buzzword level. Do their foreign keys have referential actions and deferrability? Is log based master slave replication all there can be? And surely do we have something that compares to *their* roadmap. That they cannot find it is because it's named HISTORY. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] MySQL vs PostgreSQL.
On Fri, 2002-10-11 at 08:20, Antti Haapala wrote: > Quoted from one page > > Because we couldn't get vacuum() to work reliable with PostgreSQL 7.1.1, I have little respect for the MySQL advocacy guys. They purposely spread misinformation. They always compare their leading edge alpha software against Postgres' year+ old stable versions. In some cases, I've seen them compare their alpha (4.x) software against 7.0. Very sad that these people can't even attempt to be honest. In the case above, since they are comparing 4.x, they should be comparing it to 7.x at least. It's also very sad that their testers don't seem to even understand something as simple as cron. If they can't understand something as simple as cron, I fear any conclusions they may arrive at throughout their testing (destined to be incorrect/invalid). > MySQL supports data compression between front and back ends. This could be > easily implemented, or is it already supported? Mammoth has such a feature...or at least it's been in development for a while. If I understood them correctly, it will be donated back to core sometime in the 7.5 or 7.7 series. Last I heard, their results were absolutely wonderful. > > I think all the other statements were misleading in the sense, that they > compared their newest product with PostgreSQL 7.1.1. Ya, historically, they go out of their way to ensure unfair comparisons. I have no respect for them. > > They could be provided one... ;-) In other words, they need a list of features that they can one day hope to add to MySQL. > > > Upgrading MySQL Server is painless. When you are upgrading MySQL Server, > > you don't need to dump/restore your data, as you have to do with most > > PostgreSQL upgrades. > > Ok... this is true, but not so hard - yesterday I installed 7.3b2 onto my > linux box. > > Of course PostgreSQL isn't yet as fast as it could be. ;) > I consider this par for the course. This is something I've had to do with Sybase, Oracle and MSSQL. Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] MySQL vs PostgreSQL.
On 11 Oct 2002 at 16:20, Antti Haapala wrote: > Check out: > http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html Well, I guess there are many threads on this. You can dig around archives.. > > Upgrading MySQL Server is painless. When you are upgrading MySQL Server, > > you don't need to dump/restore your data, as you have to do with most > > PostgreSQL upgrades. > > Ok... this is true, but not so hard - yesterday I installed 7.3b2 onto my > linux box. Well, that remains as a point. Imagine a 100GB database on a 150GB disk array. How do you dump and reload? In place conversion of data is an absolute necessary feature and it's already on TODO. > Of course PostgreSQL isn't yet as fast as it could be. ;) Check few posts I have made in last three weeks. You will find that postgresql is fast enough to surpass mysql in what are considered as mysql strongholds. Of course it's not a handy win but for sure, postgresql is not slow. And for vacuum thing, I have written a autovacuum daemon that can automatically vacuum databases depending upon their activity. Check it at gborg.postgresql.org. (I can't imagine this as an advertisement of myself but looks like the one) Let thread be rested. Postgresql certaily needs some maketing hand but refuting claims in that article is not the best way to start it. I guess most hackers would agree with this.. Bye Shridhar -- Cat, n.:Lapwarmer with built-in buzzer. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] MySQL vs PostgreSQL.
On Fri, 2002-10-11 at 09:20, Antti Haapala wrote: > > Check out: > > http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html > > MySQL AB compares MySQL with PostgreSQL. I wouldn't look too far into these at all. I've tried to get ' " as identifier quote (ANSI SQL) ' corrected on the crash-me pages for us a couple of times (they say we don't support it for some reason). I've not looked, but I thought 7.1 supported rename table as well. Anyway, max table row length was wrong with 7.1 wrong too unless I'm confused as to what a blob is (is text and varchar a blob -- what about your own 10Mb fixed length datatype -- how about a huge array of integers if the previous are considered blobs?) -- Rod Taylor ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
