> > We do have in the TODO list:
> >
> > A dash(-) marks changes to be in the next release.
> >
> > and appears to be fairly accurate. Haven't hear much about people
> > claiming items for 6.4 yet.
> >
>
> Bruce,
> Item "Remove restriction that ORDER BY field must be in SELECT list", in the
> TODO list, has been completed.
Dash added to TODO. Gee, I could swear I marked that as complete
already. Strange.
>
> Stephan or Anyone,
> What is the status of the HAVING clause? I noticed that it almost made the
> 6.3.2 cut, but I haven't heard any thing for a while. I would really like to
> see this feature implemented. It is important to my user community.
It works, but has some bugs, so we dis-abled it in gram.y until it was
working perfectly. I can forward the bug reports if you wish. Stephan
was working on it, but I haven't heard anything from him in months. You
are welcome to fix it.
>
> Everyone especially Vadim,
> I agree with Marc. Row locking is huge. In my user community, it is
> unacceptable to wait for up to 30 minutes (or even one minute) for a report to
> finish so that a users can commit an invoice or commit a change to a customer
> attribute. I can deal with it for now because my databases are batch loaded
> for reporting purposes only. However, I plan to go forward with some pretty
> important projects that assume that record/page locking will exist within the
> next 12 month or so. Am I being too presumptuous?
Sounds like you need dirty read rather than row locking. If they lock a
row or the entire table, it still would cause the program to stall. I
am not saying you don't need row or page locking, just that this may not
help even if we had it.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
