From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Cursors and backwards scans and SCROLL |
Date: | 2003-03-10 02:17:26 |
Message-ID: | 00e201c2e6ab$317eb9e0$6500a8c0@fhp.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
> 3. Create a runtime parameter (GUC variable) which when set causes us
> to assume SCROLL is present even if it's not stated. Setting this
> to TRUE would allow existing applications to work without modification;
> when it's FALSE, we'd enforce the spec behavior. The trouble with this
> is the TRUE setting would likely cause materialization costs to be paid
> in very many situations where the client has no intention of fetching
> backwards.
I'd be in favour of creating whole sets of backwards-compatibility GUC's
whenever we break backwards compatibility.
eg.
use_72_compat = yes
use_73_compat = yes
or something.
And then we can define all the things that those variables will affect.
That would mean that people can upgrade to new db engine (say 7.3) without
worrying about all the failures in their applications ( eg ''::int)...
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Doug McNaught | 2003-03-10 02:32:23 | Re: Cursors and backwards scans and SCROLL |
Previous Message | Peter Eisentraut | 2003-03-10 02:10:29 | Re: Who puts the Windows binaries on the FTP server? |
From | Date | Subject | |
---|---|---|---|
Next Message | Doug McNaught | 2003-03-10 02:32:23 | Re: Cursors and backwards scans and SCROLL |
Previous Message | James Cooper | 2003-03-10 02:09:30 | types? |