Re: ECPG FETCH readahead
От | Boszormenyi Zoltan |
---|---|
Тема | Re: ECPG FETCH readahead |
Дата | |
Msg-id | 4F74B5E4.6010105@cybertec.at обсуждение исходный текст |
Ответ на | Re: ECPG FETCH readahead (Michael Meskes <meskes@postgresql.org>) |
Список | 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 по дате отправления: