Re: [HACKERS] v6.4 - What is planned...?

> > 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(at)candle(dot)pha(dot)pa(dot)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)