Re: ECPG FETCH readahead - Mailing list pgsql-hackers

From Boszormenyi Zoltan
Subject Re: ECPG FETCH readahead
Date
Msg-id 4F74B5E4.6010105@cybertec.at
Whole thread Raw
In response to Re: ECPG FETCH readahead  (Michael Meskes <meskes@postgresql.org>)
List pgsql-hackers
2012-03-29 20:34 keltezéssel, Michael Meskes írta:
> On Thu, Mar 29, 2012 at 01:03:41PM -0400, Noah Misch wrote:
>> Still, we're looking at dedicated ECPG syntax, quite visible even to folks
>> with no interest in Informix.  We have eschewed littering our syntax with
>> compatibility aids, and I like it that way.  IMO, an option to the "ecpg"
>> preprocessor is an acceptable level of muddle to provide this aid.  A DECLARE
>> CURSOR syntax extension goes too far.
> +1 from me.
>
> Let's not add special ecpg sql syntax if we don't absolutely have to.
>
> Michael

This is what I waited for, finally another opinion. I will delete this
from the grammar.

What about the other question about the 0 vs 1 distinction?

Without the second patch, 0 drives the cursor with the old
ECPGdo() code. All other values drive the cursor via the new
ECPGopen() et.al. Should we keep this behaviour? In this case
the 0 vs 1 distinction is not needed in add_cursor() as the 0
value doesn't even reach ECPGopen().

But if we consider including the second patch as well, should we
keep the "NO READAHEAD" option in the grammar and in cursor.c?
After solving the problem with WHERE CURRENT OF, this and
the 0-vs-1 distinction starts to feel pointless.

And what about the override via the environment variable?
Should it work only upwards?

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig&  Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de     http://www.postgresql.at/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Finer Extension dependencies
Next
From: Daniel Farina
Date:
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)