Re: [PATCH] Incremental sort (was: PoC: Partial sort)

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: James Coleman <jtc331(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Shaun Thomas <shaun(dot)thomas(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Date: 2020-03-23 00:54:43
Message-ID: 70ed0ba6-2941-a372-b2e6-5ffa2bb77e0e@proxel.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/23/20 1:33 AM, James Coleman wrote:
> So on the face of it we have a bit of a no-win situation. The function
> tuple_sort_method_name returns a const, but lappend wants a non-const.
> I'm not sure what the project style preference is here: we could cast
> the result as (char *) to drop the const qualifier, but that's frowned
> upon some places. Alternatively we could make a new non-const copy of
> string. Which is preferable in the postgres project style?

The PostgreSQL has places where const is explicitly casted away with the
unconstify() macro, so unless you can find a better solution that is
probably an ok option.

Andreas

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2020-03-23 00:58:14 Re: ssl passphrase callback
Previous Message James Coleman 2020-03-23 00:33:46 Re: [PATCH] Incremental sort (was: PoC: Partial sort)