From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Subject: | Re: Large writable variables |
Date: | 2018-10-16 17:17:02 |
Message-ID: | 2638.1539710222@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-10-16 12:41:44 -0400, Robert Haas wrote:
>> In terms of a function that returns both const and non-const
>> variables, it seems a bit sketchy that the caller would know what the
>> function is doing in particular cases and make decisions based on it,
>> but maybe that's just how life is.
> I don't think it's necessary the callers doing so in most cases. E.g. in
> the DestReceiver case, it'll be the choice of the testreceiver (say
> intorel_receive modifying things for DestIntoRel), not the caller
> choosing when to modify things. The caller / users of dest receivers
> won't necessarily know.
Yeah, I think the use-case is more like "this API specifies non-const
pointers, but some instances can return pointers to const objects,
while others return non-const objects". Changing the API to const
isn't better, it just moves where you have to cast away const.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-10-16 19:13:43 | Re: Large writable variables |
Previous Message | Andres Freund | 2018-10-16 16:50:03 | Re: Large writable variables |