Thread
-
v6.4.3 ?
Jan Wieck <jwieck@debis.com> — 1999-02-07T17:30:43Z
For discussion: I've committed two little changes to CURRENT and REL6_4. 1. ExecBRDeleteTriggers() now free's the return tuple from the trigger procedure if that isn't the tuple given to it as OLD. This caused PL/pgSQL triggers BEFORE DELETE to let backend grow until transaction end. 2. The CHECK constraint qualification trees are only generated once per query in ExecRelCheck(). EState has a new field es_result_relation_constraints (a List**). ExecConstraints() and ExecRelCheck() get the actual EState as parameter. The fact that the constraints qualifications where read in with nodeToString() from ccbin for every single tuple also caused the backend to grow until transaction end. Especially the second fix is important. We already had reports from users of v6.4.2 who ran out of memory when doing a COPY FROM to tables that have CHECK constraints. And it would also occur on INSERT and UPDATES for those tables if many rows affected. Now that we are going to start v6.5 BETA, isn't it good to put out v6.4.3 before the hot time begins? And if we find bugs during v6.5 BETA that could also be fixed in REL6_4, do so and put out a v6.4.4 the same time we release v6.5.1. I think this would be a good release strategy. From my experience with one of the biggest commercial software products, SAP R/3, I know that it is a safe way for productional (mission critical) installations to follow releases this way: 1. Wait for the first bugfix release of a new version. 2. Use the time between the first and the second bugfix release to adapt new features into the local applications. 3. Test the second bugfix release with the result of step 2 and upgrade production. If the first bugfix release can stand for a time long enough without further bugs reported, use that for this step. 4. Follow subsequent bugfix releases if the fixes in them do or could be expected to happen in the production. Doing it this way means, that a mission critical installation will use v6.4.* until some time after we've put out at least v6.5.1. Thus, we should care about them. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] v6.4.3 ?
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-02-07T20:33:43Z
> 3. Test the second bugfix release with the result of step 2 > and upgrade production. If the first bugfix release can > stand for a time long enough without further bugs > reported, use that for this step. > > 4. Follow subsequent bugfix releases if the fixes in them do > or could be expected to happen in the production. > > Doing it this way means, that a mission critical installation > will use v6.4.* until some time after we've put out at least > v6.5.1. Thus, we should care about them. Now I see why you patching against 6.4. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] v6.4.3 ?
Marc G. Fournier <scrappy@hub.org> — 1999-02-07T20:45:03Z
On Sun, 7 Feb 1999, Bruce Momjian wrote: > > 3. Test the second bugfix release with the result of step 2 > > and upgrade production. If the first bugfix release can > > stand for a time long enough without further bugs > > reported, use that for this step. > > > > 4. Follow subsequent bugfix releases if the fixes in them do > > or could be expected to happen in the production. > > > > Doing it this way means, that a mission critical installation > > will use v6.4.* until some time after we've put out at least > > v6.5.1. Thus, we should care about them. > > Now I see why you patching against 6.4. The arguments for a v6.4.3 make sense to me...tell me when you wish for this to be created, and it shall be done :) Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] v6.4.3 ?
Jan Wieck <jwieck@debis.com> — 1999-02-07T21:06:03Z
> > Doing it this way means, that a mission critical installation > > will use v6.4.* until some time after we've put out at least > > v6.5.1. Thus, we should care about them. > > Now I see why you patching against 6.4. That's the reason. One of the biggest drawbacks against Postgres is (for many companies at least), that you can't buy support. If we only care a little for the last official release branch, it'll be much better than any payable support for a commercial product. Yes, I believe it - we have the power. I recall some replies to recent problem reports on v6.3.2 where we told "upgrade to v6.4.2" (shame on us). That's easier said than done, if someone has big applications breaking on new features. I know that it isn't true, but these "upgrade to another release" answers instead of "install bugfix release vX.X.X" look like we don't care about anyone who really uses Postgres, not only playing around with it just for fun. That's the sound of M$. Patching against v6.4 takes time. It must be done manually nearly all the time since patches don't apply clean. But it's the only way to give Postgres a real good reputation. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] v6.4.3 ?
Jan Wieck <jwieck@debis.com> — 1999-02-07T21:30:00Z
Marc G. Fournier wrote: > On Sun, 7 Feb 1999, Bruce Momjian wrote: > > > Now I see why you patching against 6.4. > > The arguments for a v6.4.3 make sense to me...tell me when you wish for > this to be created, and it shall be done :) A week or so before we start v6.5 BETA will be enough so I have the time to build the v6.4.3 feature patch before having to respond to v6.5 BETA calls. Don't remember what's all fixed between v6.4.2 and now. Does anyone else know about bugs that are still in the REL6_4 branch and could be fixed without adding features? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] v6.4.3 ?
Tom Lane <tgl@sss.pgh.pa.us> — 1999-02-07T22:51:08Z
jwieck@debis.com (Jan Wieck) writes: > Don't remember what's all fixed between v6.4.2 and now. > Does anyone else know about bugs that are still in the REL6_4 > branch and could be fixed without adding features? I just checked in the ". conftest.sh" -> ". ./conftest.sh" fix to configure, which several people have complained of (6.4.2 fails if "." is not in your PATH at configure time). We have to be pretty careful with these back-rev patches, since they typically aren't going to get much testing in the back version's CVS tree. So I'm leery of applying anything that hasn't been tested for a while in the development branch. For example, the patch I just applied to CURRENT to link libpgtcl.so with -lcrypt perhaps ought to go into REL6_4 --- but I'm afraid to do that until we verify that it works on a variety of platforms. It fixes things on teo's Linux box but I worry that it might actually break things elsewhere. regards, tom lane
-
Re: [HACKERS] v6.4.3 ?
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-02-07T23:40:57Z
I will update the stuff in the REL6_4 tree for 6.4.3. > On Sun, 7 Feb 1999, Bruce Momjian wrote: > > > > 3. Test the second bugfix release with the result of step 2 > > > and upgrade production. If the first bugfix release can > > > stand for a time long enough without further bugs > > > reported, use that for this step. > > > > > > 4. Follow subsequent bugfix releases if the fixes in them do > > > or could be expected to happen in the production. > > > > > > Doing it this way means, that a mission critical installation > > > will use v6.4.* until some time after we've put out at least > > > v6.5.1. Thus, we should care about them. > > > > Now I see why you patching against 6.4. > > The arguments for a v6.4.3 make sense to me...tell me when you wish for > this to be created, and it shall be done :) > > Marc G. Fournier > Systems Administrator @ hub.org > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 -
Re: [HACKERS] v6.4.3 ?
Sascha Schumann <sas@schell.de> — 1999-02-08T00:15:19Z
On Sun, Feb 07, 1999 at 05:51:08PM -0500, Tom Lane wrote: > jwieck@debis.com (Jan Wieck) writes: > > Don't remember what's all fixed between v6.4.2 and now. > > Does anyone else know about bugs that are still in the REL6_4 > > branch and could be fixed without adding features? > > I just checked in the ". conftest.sh" -> ". ./conftest.sh" fix to > configure, which several people have complained of (6.4.2 fails > if "." is not in your PATH at configure time). > > We have to be pretty careful with these back-rev patches, since they > typically aren't going to get much testing in the back version's > CVS tree. So I'm leery of applying anything that hasn't been tested > for a while in the development branch. > > For example, the patch I just applied to CURRENT to link libpgtcl.so > with -lcrypt perhaps ought to go into REL6_4 --- but I'm afraid to do > that until we verify that it works on a variety of platforms. It fixes > things on teo's Linux box but I worry that it might actually break things > elsewhere. Just a short note: -lcrypt is available on glibc 2 systems only. And yes please release a 6.4.3. As a administrator of some sites which rely on PostgreSQL heavily I would never use a zero-numbered version. The risk is just too high and too unforseeable. An example: Before 6.4, we used a table called "user" without any problems. Unfortunately, this was not possible in 6.4.x, because it became a reserved keyword there. Having one release together with maintenance updates minimizes the risk of getting features you don't want. -- Regards, Sascha Schumann | Consultant | finger sas@schell.de | for PGP public key -
Re: [HACKERS] v6.4.3 ?
Jan Wieck <jwieck@debis.com> — 1999-02-08T01:07:32Z
Tom Lane wrote: > We have to be pretty careful with these back-rev patches, since they > typically aren't going to get much testing in the back version's > CVS tree. So I'm leery of applying anything that hasn't been tested > for a while in the development branch. Over careful! They might rely on new features that aren't there. So it's better to wait for a v6.4.* based bug report and fix them by hand instead of appying complete patches that fix it on the fly. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] v6.4.3 ?
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-02-08T02:41:47Z
> That's the reason. One of the biggest drawbacks against > Postgres is (for many companies at least), that you can't buy > support. > > If we only care a little for the last official release > branch, it'll be much better than any payable support for a > commercial product. Yes, I believe it - we have the power. > > I recall some replies to recent problem reports on v6.3.2 > where we told "upgrade to v6.4.2" (shame on us). That's > easier said than done, if someone has big applications > breaking on new features. I agree. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] v6.4.3 ?
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-02-08T02:45:55Z
> Marc G. Fournier wrote: > > > On Sun, 7 Feb 1999, Bruce Momjian wrote: > > > > > Now I see why you patching against 6.4. > > > > The arguments for a v6.4.3 make sense to me...tell me when you wish for > > this to be created, and it shall be done :) > > A week or so before we start v6.5 BETA will be enough so I > have the time to build the v6.4.3 feature patch before having > to respond to v6.5 BETA calls. > > Don't remember what's all fixed between v6.4.2 and now. > > Does anyone else know about bugs that are still in the REL6_4 > branch and could be fixed without adding features? OK. I will make a 6.5 changes list, and you can see what we have. Do you want to make it as a patch, or a full release with a release number? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] v6.4.3 ?
Michael Meskes <michael_meskes@topmail.de> — 1999-02-08T07:47:33Z
On Sun, Feb 07, 1999 at 10:06:03PM +0100, Jan Wieck wrote: > I recall some replies to recent problem reports on v6.3.2 > where we told "upgrade to v6.4.2" (shame on us). That's > easier said than done, if someone has big applications > breaking on new features. Agreed. > I know that it isn't true, but these "upgrade to another > release" answers instead of "install bugfix release vX.X.X" > look like we don't care about anyone who really uses > Postgres, not only playing around with it just for fun. > That's the sound of M$. And once more I agree. > Patching against v6.4 takes time. It must be done manually > nearly all the time since patches don't apply clean. But it's > the only way to give Postgres a real good reputation. I like this approach. However, when d we stop maintaining the old version? I think there are still people using 6.3 who cannot simply upgrade to 6.4. So do we create 6.3.3 too? Or are there no open bug reports on 6.3 anymore? Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!
-
Commercial support, was Re: [HACKERS] v6.4.3 ?
Terry Mackintosh <terry@terrym.com> — 1999-02-08T13:32:01Z
Hi all > > That's the reason. One of the biggest drawbacks against > > Postgres is (for many companies at least), that you can't buy > > support. IMHO ... Well, yes one can, one may just need to look around a bit... and pay commercial support prices. Example: As for my self I feel confident that I could provide such support, having been using Postgres+ since Postgres 0.95? (3?4 years ago?). I charge $25/hour, but have been considering going to $30/hour. While I've yet to get a PostgreSQL specific job, I have had some other Linux based jobs. I'll bet that there are many people scattered around the globe that can also provide such support. Perhaps it might be of benefit to both the PostgreSQL image and companies considering using PostgreSQL if there where a support team around the world that could be called on. So, that said, what does every one think of the idea of maintaining on the PostgreSQL web site a contact list of "Authorized Support Centers"? Presto, instant commercial support around the globe. In addition, some time back there was a lot of talk about how to raise some money to support PostgreSQL development. Well, what if 2%? 5%? or so of money earned (related to PostgreSQL) from such official support centers went back to the PostgreSQL development group (what ever that is.). PostgreSQL is one of the top 2 or 3 choices to run on Linux, maybe the 1st choice. And Linux is now exploding in popularity, both in the home and in the company (I just came from a job where half the computers where Linux boxes -- ~40 employees, all with computers.) So, this means that the need for such support will become acute in the next year or two, and if PostgreSQL already has such a system in place and debugged, then that alone could put PostgreSQL way out ahead of all the other choices. Just my thoughts on the matter. Thanks for reading this far, Have a great day Terry Mackintosh <terry@terrym.com> http://www.terrym.com sysadmin/owner I'm excited about life! How about YOU!? Proudly powered by R H Linux 4.2, Apache 1.3.x, PHP 3.x, PostgreSQL 6.x ----------------------------------------------------------------------- Only if you know where you're going can you get there.
-
Re: Commercial support, was Re: [HACKERS] v6.4.3 ?
Jan Wieck <jwieck@debis.com> — 1999-02-08T14:11:49Z
Terry Mackintosh wrote: > > Hi all > > > > That's the reason. One of the biggest drawbacks against > > > Postgres is (for many companies at least), that you can't buy > > > support. > > IMHO ... > > Well, yes one can, one may just need to look around a bit... and pay > commercial support prices. > > Example: > As for my self I feel confident that I could provide such support, having > been using Postgres+ since Postgres 0.95? (3?4 years ago?). I charge > $25/hour, but have been considering going to $30/hour. While I've yet to > get a PostgreSQL specific job, I have had some other Linux based jobs. > > [...] Nice idea. But a word of caution seems appropriate. Commercial support doesn't mean only that you can hire someone who takes care about your actual problems with the product. It also means that there is someone you can bill if that product caused big damage to you (product warranty). Commercial support doesn't mean only that you hire someone on a T/M base (time and material). It also means that you can sign a support contract with a regular payment and have written down response- and maximum problem-to-fix times, escalation levels etc. For these issues (and there are more) you would need an assurance in the background (or a big company). But this requires that you have quality assurance management on top of the development. And that you have aggreed procedures where escalation levels from your support activate the core developers in specified times to solve problems. And it requires that you have more precise product specifications telling what the product can and where it's limits are. Otherwise you wouldn't be able to pay the assurance. There are already distributions of Linux out where you can buy commercial support with them. They stay behind the bleeding edge of development and are offered by companies, that have their own development team apart from the internet community. Looking at how we are organized (or better unorganized), all this high level commercial support seems far away. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: Commercial support, was Re: [HACKERS] v6.4.3 ?
Thomas Reinke <reinke@e-softinc.com> — 1999-02-08T14:56:50Z
Jan Wieck wrote: > > Terry Mackintosh wrote: > > > > > Hi all > > > > > > That's the reason. One of the biggest drawbacks against > > > > Postgres is (for many companies at least), that you can't buy > > > > support. > > > > IMHO ... > > > > Well, yes one can, one may just need to look around a bit... and pay > > commercial support prices. > > > > Example: > > As for my self I feel confident that I could provide such support, having > > been using Postgres+ since Postgres 0.95? (3?4 years ago?). I charge > > $25/hour, but have been considering going to $30/hour. While I've yet to > > get a PostgreSQL specific job, I have had some other Linux based jobs. > > > > [...] > > Nice idea. > > But a word of caution seems appropriate. > > Commercial support doesn't mean only that you can hire > someone who takes care about your actual problems with the > product. It also means that there is someone you can bill if > that product caused big damage to you (product warranty). > > Commercial support doesn't mean only that you hire someone on > a T/M base (time and material). It also means that you can > sign a support contract with a regular payment and have > written down response- and maximum problem-to-fix times, > escalation levels etc. > Usage decisions also depend on one other MAJOR factor, which Linux has conquered, but I personally feel that PostGres is still a bit shy on: reliability. We use PostGres commercially, and quite frankly have a tough time with it, because of consistent failures with it. Although the price is right, and we hope to stick with PostGres as it matures into a more robust product, others would not touch it when you consider the following reliability problems (admittedly all reported on 6.3): 1. Tables "disappearing" while still listed in the db directory (but no longer visible from the client) 2. Tables being corrupted (i.e. not selectable, not vacuumable, not exportable) 3. Vacuum commands that take longer to run after one day of table updates than if the table was to be dumped and reloaded (e.g. table with 1.7 million rows, 200,000 rows being updated each day) 4. An inability to run multiple clients simultaneously without having the backends choke and kick everybody out (we've had to implement a lock manager that restricts db access to one client at a time) (Part of the test suite should be an 8 hour or so load test that has multiple clients reading/writing to the same/different tables...might be surprised what you find) 5. Memory leaks/poor mem management in various components that need to be worked around (vacuum, insert of existing rec into uniquely indexed table) Linux is successful because it is reliable, and because many folks are WILLING to risk an OS that has the perception of being unsupported, if once they install it it will run cleanly. However, anyone using a database for any sort of serious application will generally have a more stringent set of criteria that they apply to their selection process. I.e. PostGres is tackling a tougher market than Linux is tackling, and it will have to be correspondingly more mature in order to enjoy the same success. Reword? We would be happier if someone were to iron all the problems out of postgres that make it unreliable, and not very robust, than if someone were to provide commercial support (which will NOT fix the aforementioned problems!) Thomas ------------------------------------------------------------ Thomas Reinke Tel: (416) 460-7021 Director of Technology Fax: (416) 598-2319 E-Soft Inc. http://www.e-softinc.com -
Re: [HACKERS] v6.4.3 ?
Marc G. Fournier <scrappy@hub.org> — 1999-02-08T17:50:12Z
On Mon, 8 Feb 1999, Michael Meskes wrote: > On Sun, Feb 07, 1999 at 10:06:03PM +0100, Jan Wieck wrote: > > I recall some replies to recent problem reports on v6.3.2 > > where we told "upgrade to v6.4.2" (shame on us). That's > > easier said than done, if someone has big applications > > breaking on new features. > > Agreed. > > > I know that it isn't true, but these "upgrade to another > > release" answers instead of "install bugfix release vX.X.X" > > look like we don't care about anyone who really uses > > Postgres, not only playing around with it just for fun. > > That's the sound of M$. > > And once more I agree. > > > Patching against v6.4 takes time. It must be done manually > > nearly all the time since patches don't apply clean. But it's > > the only way to give Postgres a real good reputation. > > I like this approach. However, when d we stop maintaining the old version? I > think there are still people using 6.3 who cannot simply upgrade to 6.4. So > do we create 6.3.3 too? Or are there no open bug reports on 6.3 anymore? One version back, in my opinion...v6.5's release kills anythingolder then v6.4, v6.6's release kills anything older then v6.5, etc... And, no, we aren't "supporting" v6.3 at this time, since this is a new thing... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] v6.4.3 ?
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-02-08T18:13:15Z
> I like this approach. However, when d we stop maintaining the old version? I > think there are still people using 6.3 who cannot simply upgrade to 6.4. So > do we create 6.3.3 too? Or are there no open bug reports on 6.3 anymore? We keep releasing versions until no show-stopper bugs exist. 6.4.* had one on COPY bug that Jan is fixing. The others have workarounds, and we are so quick at pointing people to these work-arounds, I don't think they warrant a new release. We get so many improvements with each release, it is tough to back-patch those into the tree. At some point, the 6.3.* tree would match the 6.4.* tree. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] v6.4.3 ?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-02-09T02:49:45Z
> We keep releasing versions until no show-stopper bugs exist. > 6.4.* had one on COPY bug that Jan is fixing. The others have > workarounds, and we are so quick at pointing people to these > work-arounds, I don't think they warrant a new release. I posted one or two patches into the /pub/patches directory, and am not sure whether I bothered installing them into the v6.4.x tree since it may have been declared dead at that point. Be sure and check (or get a message from me after I've checked) that they have been applied before releasing v6.4.3... - Tom -
Re: [HACKERS] v6.4.3 ?
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-02-09T03:01:50Z
> > We keep releasing versions until no show-stopper bugs exist. > > 6.4.* had one on COPY bug that Jan is fixing. The others have > > workarounds, and we are so quick at pointing people to these > > work-arounds, I don't think they warrant a new release. > > I posted one or two patches into the /pub/patches directory, and am not > sure whether I bothered installing them into the v6.4.x tree since it > may have been declared dead at that point. Be sure and check (or get a > message from me after I've checked) that they have been applied before > releasing v6.4.3... > We can't just do 6.4.2 patches, can we? That would be nice. We getting near starting beta, and will not have lots of time to test things. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] v6.4.3 ?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-02-09T14:51:24Z
> We can't just do 6.4.2 patches, can we? That would be nice. We > getting near starting beta, and will not have lots of time to test > things. Personally, I would choose to post patches, since as you point out we are really focused on v6.5beta. We *still* need a patch convention with a .../patches/ directory shipped with Postgres, and with routines to help create and apply the patches. I would suggest that for the future we create a top level directory called "patches", and within that directory have two routines, perhaps CreatePatch, CreatePackage, and ApplyPatch. CreatePatch would create a subdirectory, look for all .orig files and make separate patch files for each inside the subdirectory. Type a README and post a tar file of the subdirectory at ftp://postgresql.org/pub/patches/. On the other end, ApplyPatch could print the README, prompt for an "OK to continue?", and apply the specified patches. If there is already a common package for doing this we could use that of course. I might have time to do this for v6.5 unless someone else wants to give it a shot. I have some code which could form the basis for this (and I know that Bruce has something in the source tree which he uses but which imho does not have enough of the features mentioned above; my current code is lacking some of these also)... - Tom