| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, Lee McKeeman <lmckeeman(at)opushealthcare(dot)com> |
| Subject: | Re: [BUGS] Status of issue 4593 |
| Date: | 2009-01-12 13:32:38 |
| Message-ID: | 28174.1231767158@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I can see two ways forward:
> 1) We document bluntly that ORDER BY + FOR UPDATE can return unordered
> results, or
> 2) We prohibit ORDER BY + FOR UPDATE, like we do with a number of other
> clauses. (There would be no loss of functionality, because you can run
> the query a second time in the transaction with ORDER BY.)
That code has been working like this for eight or ten years now and this
is the first complaint, so taking away functionality on the grounds that
someone might happen to update the ordering column doesn't seem like the
answer to me.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2009-01-12 14:03:09 | Re: [BUGS] Status of issue 4593 |
| Previous Message | Peter Eisentraut | 2009-01-12 13:26:48 | Re: [BUGS] Status of issue 4593 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2009-01-12 13:37:51 | Re: Sample of user-define window function and other things |
| Previous Message | Tom Lane | 2009-01-12 13:27:10 | Re: Proposal: new border setting in psql |