From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, pgsql-sql(at)postgreSQL(dot)org |
Subject: | Re: Cursors and backwards scans and SCROLL |
Date: | 2003-03-10 07:14:38 |
Message-ID: | 1047280477.2892.11.camel@fuji.krosing.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
Tom Lane kirjutas P, 09.03.2003 kell 22:35:
> However, this is going to create backwards-compatibility issues.
> We have a few options for what to do:
>
> 1. Enforce the SQL spec requirement: error out if backwards fetch is
> done when SCROLL wasn't given. But this will surely break a lot
> of existing applications that work perfectly well.
We could start by issuing a NOTICE/WARNING as a step towards the strict
compliance and provide a GUC variable for those who are unable to cope
even with the warning.
The warning could be issued at two places -
1. ( more annoying ) issue it at cursor creation time when a plan is
chosen that can't be fetched backwards.
2. like your #2, but just give a warning and then run the underlying
query _again_, this toime with materialize on top and also do a Move to
reposition the cursor. This will probably not work correctly for all
tranasaction isolation levels though but it will penalize only these
cases that absolutely need it. The penalty will of course be heavier ;(
-----------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2003-03-10 08:21:01 | Re: Who puts the Windows binaries on the FTP server? |
Previous Message | Hannu Krosing | 2003-03-10 06:57:53 | Re: SQL99 ARRAY support proposal |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomasz Myrta | 2003-03-10 09:12:15 | Re: Help on indexing timestamps |
Previous Message | jack | 2003-03-10 04:48:27 | Re: About Create Type |