Date: Tue, 3 Sep 2019 18:02:54 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Nikita Glukhov <n.gluhov@postgrespro.ru>,
	Nikolay Shaplov <dhyan@nataraj.su>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
	Oleg Bartunov <obartunov@gmail.com>
Subject: Re: [PATCH] Opclass parameters
Message-ID: <20190903220254.GA22389@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190611175745.wwb6jywbch2pz23f@development>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

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.

> 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.

Anyway, this patchset doesn't apply anymore.  Somebody (maybe its
author this time?) please rebase.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services