Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gK3Tw-0007YR-Qc for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Nov 2018 15:41:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gK3Tu-0001Jl-SX for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Nov 2018 15:41:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gK3Tu-0001Je-LY for pgsql-hackers@lists.postgresql.org; Tue, 06 Nov 2018 15:41:30 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gK3To-0001ZW-3i for pgsql-hackers@postgresql.org; Tue, 06 Nov 2018 15:41:30 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B2493A402B; Tue, 6 Nov 2018 15:41:20 +0000 (UTC) Received: from nb.usersys.redhat.com (unknown [10.43.2.86]) by smtp.corp.redhat.com (Postfix) with ESMTP id C55E91711C; Tue, 6 Nov 2018 15:41:19 +0000 (UTC) From: Pavel Raiskup To: Tom Lane Cc: Robert Haas , "pgsql-hackers@postgresql.org" , Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= Subject: Re: plruby: rb_iterate symbol clash with libruby.so Date: Tue, 06 Nov 2018 16:41:16 +0100 Message-ID: <1630033.SqB3vyA3BZ@nb.usersys.redhat.com> In-Reply-To: <22881.1541515786@sss.pgh.pa.us> References: <4738198.8KVIIDhgEB@nb.usersys.redhat.com> <1772202.Bn4MKCBuZf@nb.usersys.redhat.com> <22881.1541515786@sss.pgh.pa.us> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 06 Nov 2018 15:41:20 +0000 (UTC) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tuesday, November 6, 2018 3:49:46 PM CET Tom Lane wrote: > Pavel Raiskup writes: > > On Monday, November 5, 2018 9:06:41 PM CET Robert Haas wrote: > >> On Sat, Nov 3, 2018 at 2:20 PM Tom Lane wrote: > >>>> Is it realistic we could rename red-black tree methods from 'rb_*' to e.g. > >>>> 'rbt_*' to avoid this clash? > > >>> I don't have a huge objection to renaming the rbtree functions, other > >>> than the precedent it sets ... > > >> Maybe prefixing with pg_ would better than rb_ to rbt_. ... > >> It's certainly not very surprising that Ruby has symbols starting with > >> rb_... > > > I now realized that there's rb_block_call() alternative for rb_iterate() > > Ruby call -- which fortunately doesn't collide with PostgreSQL internals. > > It means that for sufficiently new Ruby there exists some solution (not > > that something similar can not re-appear elsewhere). > > Yeah. The long and short of this is that we're trampling on namespace > that reasonably belongs to Ruby --- if they had some functions named > "pg_something" and complained about a collision with libpq, would we > change? Nope. So really we should rename these. > > After looking at the code a bit I like the idea of s/rb/rbt/g > better than s/rb/pg_rb/g. The latter seems verbose, and it would > also open the question of whether we need to rename rbtree.h/.c, > which would be an additional level of complication I don't want. > The rbt approach will allow skipping some other renamings that > would be needed for consistency if we use pg_rb. > > Barring objections I'll go make this happen shortly. > > It's too late for this week's releases, but Pavel could pick up the commit > once it happens and carry it as a Fedora patch until the next releases. Thanks for looking at that, and no problem with this release. To make plruby work against supported PostgreSQL versions we'll have to first fix quite a few _other_ legacy problems first. Pavel