Poorly named support routines for GIN tsearch index opclasses - Mailing list pgsql-hackers

From Tom Lane
Subject Poorly named support routines for GIN tsearch index opclasses
Date
Msg-id 12431.1196201871@sss.pgh.pa.us
Whole thread Raw
Responses Re: Poorly named support routines for GIN tsearch index opclasses  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
I've just noticed that tsearch includes a couple of support functions
with rather vague names:gin_extract_query(internal,internal,smallint)gin_ts_consistent(internal,smallint,internal)
These are, in fact, specialized to the case of operating on tsquery
inputs, but you'd never guess that from either the name or the
declared argument types.  The first one seems particularly likely
to conflict with other peoples' GIN opclasses, down the road sometime.

Since we've already forced initdb for the next beta, it would be "free"
to rename these things now.  I don't believe this would cause any
compatibility problems for applications, since SQL queries never call
these things directly.  I'm thinking "gin_extract_tsquery" and
"gin_tsquery_consistent" would be suitable names.

Another possibility would be to change the declared signatures to show
"tsquery" rather than "internal" at the places where a tsquery argument
is expected.  I'm less excited about that part though.

Comments, objections?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Brendan Jurd"
Date:
Subject: Re: [GENERAL] Empty arrays with ARRAY[]
Next
From: Tom Lane
Date:
Subject: Still a NOTICE in dict_thesaurus.c