Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors
Date
Msg-id 20454.1395505337@sss.pgh.pa.us
Whole thread Raw
In response to Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors  (Piotr Stefaniak <postgres@piotr-stefaniak.me>)
List pgsql-hackers
Piotr Stefaniak <postgres@piotr-stefaniak.me> writes:
> Apart from what the page says, I also think of casting malloc() as bad 
> style and felt the need to bring this up.

Well, that's a value judgement I don't happen to agree with.  Yeah, it'd
be better if the language design were such that we could avoid explicit
casting everywhere, but in this context casting is less risky than not
casting.

> So perhaps this alternative:
>    myextra = malloc(sizeof *myextra);

[ shrug... ]  That's about a wash for this exact use case, but it gets
messy as soon as the lefthand side is anything more complicated than a
simple variable name.  And it doesn't scale to cases where the malloc
result isn't directly assigned to anything --- for example, what if
you want to pass the result of palloc() directly to some other
function, or return it from the current function?

The bigger picture though is that the style with the explicit cast is
already extremely widely used in Postgres.  That being the case,
conforming to project style is better than using some inconsistent
convention, regardless of your personal views about whether there's a
better way to do it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Piotr Stefaniak
Date:
Subject: Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors
Next
From: Piotr Stefaniak
Date:
Subject: Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors