Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group