Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i7oOp-0007Af-TB for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Sep 2019 22:14:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i7oOo-0005Vo-Pm for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Sep 2019 22:14:10 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1i7oOo-0005R0-DD for pgsql-hackers@lists.postgresql.org; Tue, 10 Sep 2019 22:14:10 +0000 Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i7oOk-0001DU-JQ for pgsql-hackers@postgresql.org; Tue, 10 Sep 2019 22:14:09 +0000 Received: by mail-wm1-x341.google.com with SMTP id o184so1207106wme.3 for ; Tue, 10 Sep 2019 15:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=4yhJIW3UXzxViqTEKvc9z6gdUTEUSA/Bxs83JKc1Thk=; b=tldv+ZnadnnvyZZ/qCe7TsLlyy4sVsY12LpvH3uwi9ip2UnhsbmovrdKyanFOXtuA3 ToEISayQgM+EeTFwmXKvsQXFH4J57REhn2aJ+bL9n5r/Q651ZtblAg+ViSSpzziSbjyd o5xjBYaZe3FFA9Wm0Qjcj6Fp9H6RkflMLO05YsOL2aRKO5Wfc2HLJi31rS9tXqTEpktq barRyvwdy1rnNphSP0tsKVg7Z94DWHZBfCKmxTRiSzVSgNGdhFg0vNgl087kzVgnXJ4l y5Asw7fKEsrroRsYVnYqorZ0MwGiMvJ9/MMgwu8CLaidlc8O5tHg24BHBV/GkCyanJZi uyKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=4yhJIW3UXzxViqTEKvc9z6gdUTEUSA/Bxs83JKc1Thk=; b=Dp2yudXqBgECxFOsnUnIjAke48RwpdZQIMDd0Mi9q/ahjuEgdyS6w0yJ2sbBU80XxQ cR3POqH8f6jpjke6jVJnqrnS3OOigbYYl+unozkTaE3l3iWcBIrVBXaAmU5uLLBodwQu TolMalsM0LyyhqwZMZmipGFhTkodlHDtKXuxEYFYUgBKgNpxZ9YXGaOD+a4yFmUk504P gFDNLYJxfLej6VA+kwiQfaIDGWbak+Gb/EDYwx6o6x1Vdd+seuzls0m53R9LlKzdCvm0 J6imzO89ixO73PKiLDaeebGTX8YYSmwcGNlguUf2Iye8XioXpeQjvtIBzMGhSSVgw82b JBpA== X-Gm-Message-State: APjAAAUlZyMkZnrvXFm5qnTNmiM/dfJlPllGJntX82RCGrt9LuW5JZ/F UuwCfnC9W7ChrKZRe+DB2iHpUg== X-Google-Smtp-Source: APXvYqwqgxZi0UFIFRA9czPCPHLIURae1LME+CfLUgxQmR3jWuCC81JrVPaSP3HDmt9jExTGbzu+eQ== X-Received: by 2002:a7b:c92d:: with SMTP id h13mr1327629wml.86.1568153645707; Tue, 10 Sep 2019 15:14:05 -0700 (PDT) Received: from localhost ([88.157.94.57]) by smtp.gmail.com with ESMTPSA id q25sm1084907wmq.27.2019.09.10.15.14.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Sep 2019 15:14:05 -0700 (PDT) Date: Wed, 11 Sep 2019 00:14:01 +0200 From: Tomas Vondra To: Nikita Glukhov Cc: Alvaro Herrera , "pgsql-hackers@postgresql.org" , Robert Haas , Tom Lane , Nikolay Shaplov , Oleg Bartunov Subject: Re: [PATCH] Opclass parameters Message-ID: <20190910221401.ebw6kgsb4ziqtqmg@development> References: <20190903220254.GA22389@alvherre.pgsql> <20190910220358.6tj37k4v6vyaqac7@development> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190910220358.6tj37k4v6vyaqac7@development> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Sep 11, 2019 at 12:03:58AM +0200, Tomas Vondra wrote: >On Tue, Sep 10, 2019 at 04:30:41AM +0300, Nikita Glukhov wrote: >>On 04.09.2019 1:02, Alvaro Herrera wrote: >> >>>On 2019-Jun-11, Tomas Vondra wrote: >>> >>>>1) We need a better infrastructure to parse opclass parameters. For >>>>example the gtsvector_options does this: >>>I think this is part of what Nikolay's patch series was supposed to >>>address. But that one has been going way too slow. I agree we need >>>something better. >> >>API was simplified in the new version of the patches (see below). >> >>>>2) The 0001 part does this in index_opclass_options_generic: >>>> >>>> get_opclass_name(opclass, InvalidOid, &str); >>>> >>>> ereport(ERROR, >>>> (errcode(ERRCODE_INVALID_PARAMETER_VALUE), >>>> errmsg("operator class \"%s\" has no options", >>>> opclassname.data))); >>>> >>>>But that's a bit broken, because get_opclass_name() appends the opclass >>>>name to 'str', but with a space at the beginning. >>>Yeah, I think just exporting get_opclass_name from ruleutils.c is a bad >>>idea. Sounds like we need a (very small) new function in lsyscache.c >>>that does the job of extracting the opclass name, and then the ruleutils >>>function can call that one to avoid duplicated code. >> >>I decided to add new function generate_opclass_name() like existing >>generate_collation_name(), and to reuse static get_opclass_name(). >> >>>Anyway, this patchset doesn't apply anymore. Somebody (maybe its >>>author this time?) please rebase. >> >>New version of rebased patches is attached: >> >>1. Opclass parameters infrastructure. >> >> API was completely refactored since the previous version: >> >> - API was generalized for all AMs. Previously, each AM should implement >> opclass options parsing/passing in its own way using its own support >>  function numbers. >> Now each AMs uses 0th support function (discussable). Binary bytea values >> of parsed options are passed to support functions using special expression >> node initialized in FmgrInfo.fn_expr (see macro PG_GET_OPCLASS_OPTIONS(), >> get_fn_opclass_options(), set_fn_opclass_options). >> > >I very much doubt these changes are in the right direction. Firstly, using >0 as procnum is weird - AFAICS you picked 0 because after moving it from >individual AMs to pg_amproc.h it's hard to guarantee the procnum does not >clash with other am procs. But ISTM that's more a hint that the move to >pg_amproc.h itself was a bad idea. I suggest we undo that move, instead of >trying to fix the symptoms. That is, each AM should have a custom procnum. > >Also, looking at fn_expr definition in FmgrInfo, I see this > > fmNodePtr fn_expr; /* expression parse tree for call, or NULL */ > >it seems like a rather bad idea to reuse that to pass options when it's >clearly not meant for that purpose. > BTW, is there a place where we actually verify the signature of the new am proc? Because I only see code like this: + case OPCLASS_OPTIONS_PROC: + ok = true; + break; in all "validate" functions. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services