Re: [PATCH] Opclass parameters - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [PATCH] Opclass parameters
Date
Msg-id 20190903220254.GA22389@alvherre.pgsql
Whole thread Raw
In response to Re: [PATCH] Opclass parameters  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: [PATCH] Opclass parameters
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Attempt to consolidate reading of XLOG page
Next
From: Alvaro Herrera
Date:
Subject: Re: WIP: BRIN multi-range indexes