Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>
Subject: Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors
Date: 2014-03-22 16:22:17
Message-ID: 20454.1395505337@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-03-22 16:23:37 Re: psql blows up on BOM character sequence
Previous Message Piotr Stefaniak 2014-03-22 15:53:27 Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors