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

Re: some dead code in functioncmds.c

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: some dead code in functioncmds.c
Date: 2009-10-30 18:08:13
Message-ID: 162867790910301108r2441875cg230cc2a8479ce2df@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2009/10/30 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
> Pavel Stehule wrote:
>> 2009/10/30 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
>>> Pavel Stehule wrote:
>>>>       else
>>>>       {
>>>>               ereport(ERROR,
>>>>                               (errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
>>>>                                errmsg("function result type must be specified")));
>>>>               /* Alternative possibility: default to RETURNS VOID */
>>>>
>>>> /* WHY FOLOWING LINES? */
>>>>               prorettype = VOIDOID;
>>>>               returnsSet = false;
>>>>       }
>>> To keep the compiler quiet about using the variables uninitialized. The
>>> compiler doesn't know that ereport(ERROR) never returns.
>>
>> Should be similar code little bit commented?
>
> *shrug*, maybe, often we do put a "/* keep compiler quiet */" comment on
> such places.
>
> On closer look, the "Alternative possibility: default to RETURNS VOID"
> comment suggests that besides keeping the compiler quiet, those lines
> demonstrate an alternative behavior that was considered.

I prefere "keep compiler quiet". It is cleaner - and it is used more times.

Pavel
>
> --
>  Heikki Linnakangas
>  EnterpriseDB   http://www.enterprisedb.com
>

In response to

Responses

pgsql-hackers by date

Next:From: Jeff DavisDate: 2009-10-30 18:14:22
Subject: Re: Syntax for partitioning
Previous:From: Heikki LinnakangasDate: 2009-10-30 17:12:11
Subject: Re: Syntax for partitioning

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