Horton

Re: ECPG FETCH readahead

Boszormenyi Zoltan <zb@cybertec.at>

View thread
From: Böszörményi Zoltán <zb@cybertec.at>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Bruce Momjian <bruce@momjian.us>, Michael Meskes <meskes@postgresql.org>, PG Hackers <pgsql-hackers@postgresql.org>, Hans-Juergen Schoenig <hs@cybertec.at>
Date: 2010-06-24T09:27:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix some "translator:" comments mangled by pgindent

  2. Make sure float4in/float8in accept all standard spellings of "infinity".

2010-06-24 11:04 keltezéssel, Heikki Linnakangas írta:
> On 24/06/10 10:27, Böszörményi Zoltán wrote:
>> And this readahead is not on by default, it's only activated
>> by "ecpg -r fetch_readahead".
>
> Is there a reason not to enable it by default? I'm a bit worried that 
> it will receive no testing if it's not always on.

Because in the first step I wanted to minimize the impact
on regression test stderr results. This is what I mentioned
in the initial mail, I stuck to the original wording of ecpg_log()
messages in the split-up parts of the original ECPGdo() and
ecpg_execute() exactly for this reason. The usual policy for
ecpg_log() is to report the function name where it was issued.

I was also thinking about a new feature for pg_regress,
to compare stdout results of two regression tests automatically
so a difference can be reported as an error. It would be good
for automated testing of features in ECPG that can be toggled,
like auto-prepare and fetch readahead. It might come in handy
in other subsystems, too.

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