From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <hornschnorter@gmail.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: gratuitous casting away const
In-reply-to: <96DBB26C-34FF-4090-98A8-6DDA5136AC73@gmail.com>
References: <ACF3A030-E3D5-4E68-B744-184E11DE68F3@gmail.com>
 <20919.1474402019@sss.pgh.pa.us>
 <96DBB26C-34FF-4090-98A8-6DDA5136AC73@gmail.com>
Comments: In-reply-to Mark Dilger <hornschnorter@gmail.com>
	message dated "Tue, 20 Sep 2016 14:33:17 -0700"
Date: Thu, 22 Sep 2016 12:14:43 -0400
Message-ID: <26710.1474560883@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Mark Dilger <hornschnorter@gmail.com> writes:
>> On Sep 20, 2016, at 1:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... that seems to be discarding type information in order to add
>> "const"; does not seem like a net benefit from here.

> The following seems somewhere in between, with ItemPointer
> changing to const ItemPointerData *.  I expect you would not care
> for this change, but thought I'd check to see where you draw the line:

I'd call this kind of a wash, I guess.  I'd be more excited about it if
the change allowed removal of an actual cast-away-of-constness somewhere.

I suppose it's a bit of a chicken and egg situation, in that the lack
of const markings on leaf subroutines discourages use of "const" in
callers, and you have to start somewhere if you want to make it better.
But I don't really want to just plaster "const" onto individual functions
without some larger vision of where we're going and which code is going
to benefit.  Otherwise it seems like mostly just code churn.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers