Re: Don't allocate IndexAmRoutine dynamically?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Don't allocate IndexAmRoutine dynamically?
Date: 2019-06-25 21:53:47
Message-ID: 29073.1561499627@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 2019-06-25 17:25:12 -0400, Tom Lane wrote:
>> Yeah, I think trying to make such pointer fields "const", within
>> structures that are otherwise not const, is just more trouble than it's
>> worth. To start with, how will you assign the handler's output pointer
>> to such a field?

> Yea, it's annoying. C++ is slightly cleaner in this case, but it's still not
> great. In most cases it's perfectly legal to cast the const away (that's
> always legal) *and* write through that. The standard's requirement is
> quite minimal - C99's 6.7.3 5) says:

> If an attempt is made to modify an object defined with a
> const-qualified type through use of an lvalue with non-
> const-qualified type, the behavior is undefined. ...

I'm not sure how you are parsing "the behavior is undefined" as "it's
legal". But in any case, I'm not on board with const-qualifying stuff
if we just have to cast the const away in common situations. I think
it'd be far more valuable to get to a state where cast-away-const can
be made an error.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-06-25 22:55:43 Re: Don't allocate IndexAmRoutine dynamically?
Previous Message Andres Freund 2019-06-25 21:42:52 Re: Don't allocate IndexAmRoutine dynamically?