Re: StringInfo Macros

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: StringInfo Macros
Date: 2009-08-28 19:57:39
Message-ID: 4A9836B3.6060407@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Tom,

Tom Lane wrote:
> Don't call them BUFFER_FOO --- that term already has a pretty specific
> meaning in most of the backend. STRINGINFO_FOO is a bit long but
> seems to fit the best with the existing naming in stringinfo.h.

Understood and agreed. Note however, that lots of places, especially
also pgformat.c, call the StringInfo variable "buf".

> A number of the specific things you are proposing above seem to be
> violations of the abstraction stringinfo is meant to present.

Maybe in violation of stringinfo, which is more general, but much less
WRT all of the pq_sendXX() and the corresponding pq_getmsgXX() methods.
AFAIU the former don't use the cursor and write starting from END_PTR as
long as BYTES_FREE > 0, while the later uses the cursor field and reads
from CURSOR_PTR as long as BYTES_READABLE > 0.

> It's a string, and the fact that there's any extra space beyond
> the end of the string is an internal matter.

I rather think of those as buffers to read from and write to. In that
case it makes perfect sense to append new data at the end, IMO.

On could argue, that StringInfo itself isn't the best fit, as it doesn't
necessarily hold a string. So it might be hard to find a good prefix.
PQFORMAT_ might be an option, but it's even less descriptive...

Thank you for commenting.

Regards

Markus Wanner

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-08-28 20:11:10 Re: 8.5 release timetable, again
Previous Message Andrew Dunstan 2009-08-28 19:32:55 Re: Add YAML option to explain