Re: second DML operation fails with updatable cursor

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dharmendra Goyal <dharmendra(dot)goyal(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: second DML operation fails with updatable cursor
Date: 2007-10-25 09:26:02
Message-ID: 4720612A.1020705@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> SQL92 has this under Leveling Rules:
>
> 1) The following restrictions apply for Intermediate SQL:
>
> a) A <declare cursor> shall not specify INSENSITIVE.
>
> b) If an <updatability clause> of FOR UPDATE with or without
> a <column name list> is specified, then neither SCROLL nor
> ORDER BY shall be specified.
>
> So SCROLL with FOR UPDATE is a Full-SQL-only feature. (In SQL99 it's
> broken out as Feature F831-01, but that doesn't tell you much about
> how hard it is or whether most implementations have it.)

Oh, ok then.

> I don't feel particularly bad about not supporting every such feature.
> I think Simon's recommendation is definitely the way to go for 8.3 ---
> if anyone is motivated to relax the restriction in the future, they can
> figure out how to resolve the corner cases then.

Ok. Looking at what you committed, I completely misunderstood what you
were saying earlier. Yeah, let's leave it like that for now. A nice "not
supported" error message is perfectly fine, as long as we can avoid the
unexpected behavior.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2007-10-25 09:46:35 MaxOffsetNumber versus MaxHeapTuplesPerPage
Previous Message Hubert FONGARNAND 2007-10-25 08:54:24 PostGreSQL and zlib