Robert Haas writes:
> On Thu, Oct 24, 2013 at 2:18 PM, Peter Eisentraut wrote:
>> While this is attractive, the same logic would suggest that we rename
>> pg_malloc() to palloc(), and that sounds wrong. The frontend and
>> backend functions do have different freeing semantics.
> I'd almost be i
On Thu, Oct 24, 2013 at 2:18 PM, Peter Eisentraut wrote:
> On 10/22/13, 3:40 PM, Tom Lane wrote:
>> In order to avoid having to clutter stuff like that with #ifdef FRONTENDs,
>> I'm now thinking we should use exactly the same names for the frontend and
>> backend versions, ie psprintf() and pvspri
Peter Eisentraut writes:
> On 10/22/13, 3:40 PM, Tom Lane wrote:
>> In order to avoid having to clutter stuff like that with #ifdef FRONTENDs,
>> I'm now thinking we should use exactly the same names for the frontend and
>> backend versions, ie psprintf() and pvsprintf(). The main reason for
>> c
On 10/22/13, 3:40 PM, Tom Lane wrote:
> In order to avoid having to clutter stuff like that with #ifdef FRONTENDs,
> I'm now thinking we should use exactly the same names for the frontend and
> backend versions, ie psprintf() and pvsprintf(). The main reason for
> considering a pg_ prefix for the
On 10/22/2013 11:06 PM, Tom Lane wrote:
Attached is a draft, which compiles though I've not yet actually tested it.
nprinted = vsnprintf(buf, len, fmt, args);
Assert(buf[len - 1] == '\0');
The assert may fire if len > INT_MAX and the system returns with errno
== EOVERFLOW, a
I wrote:
> Stephen Frost writes:
>> I agree that exit/Assert-or-elog is the right API here. I wonder if
>> it'd be reasonable or worthwhile to try and actually make that happen-
>> that is to say, we really do only have one implementation for both
>> front-end and back-end here, but on the front-
Alvaro Herrera writes:
> Tom Lane wrote:
>> ... BTW, another reason to choose identical APIs for frontend and backend
>> versions of these functions is that it greatly eases use of them in shared
>> frontend/backend code. As I notice somebody has *already done* in
>> common/relpath.c. I'm not e
Tom Lane wrote:
> ... BTW, another reason to choose identical APIs for frontend and backend
> versions of these functions is that it greatly eases use of them in shared
> frontend/backend code. As I notice somebody has *already done* in
> common/relpath.c. I'm not exactly sure how those psprintf
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> ... BTW, another reason to choose identical APIs for frontend and backend
> versions of these functions is that it greatly eases use of them in shared
> frontend/backend code. As I notice somebody has *already done* in
> common/relpath.c. I'm not exactly
... BTW, another reason to choose identical APIs for frontend and backend
versions of these functions is that it greatly eases use of them in shared
frontend/backend code. As I notice somebody has *already done* in
common/relpath.c. I'm not exactly sure how those psprintf calls are
working at al
Stephen Frost writes:
> I agree that exit/Assert-or-elog is the right API here. I wonder if
> it'd be reasonable or worthwhile to try and actually make that happen-
> that is to say, we really do only have one implementation for both
> front-end and back-end here, but on the front-end we exit, wh
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Sounds reasonable, and I haven't got a better name, but I'm trying to
> > figure out why psprintf hasn't got the same issues which you mention in
> > your other thread (eg: depending on vsnprintf to return the "would-be"
> > result
Stephen Frost writes:
> Sounds reasonable, and I haven't got a better name, but I'm trying to
> figure out why psprintf hasn't got the same issues which you mention in
> your other thread (eg: depending on vsnprintf to return the "would-be"
> result size).
It does, though not directly in psprintf
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> In short, I want to change pg_asprintf to return the malloc'd buffer
> as its function result. This probably means we should change the
> function name too, since the allusion to asprintf is completely useless
> if we do that. I'm thinking pg_psprint
I wrote:
> I have a lot of other gripes about this whole patch, but they can
> wait till tomorrow.
The other big thing I don't like about this patch is that adopting
asprintf() as a model was not any better thought-out than the
portability considerations were. It's a bad choice because:
1. aspri
15 matches
Mail list logo
