Thread: Poorly named support routines for GIN tsearch index opclasses
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
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > 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. The use of "internal" arguments has always been the part of GIN/GIST which bothered me the most. Most of those instances are actually quite necessary but if there are some that aren't I'm all for removing them. The only thing is that this has a semantic effect. It means users will be able to call these functions from SQL directly. Are they safe to allow this? Is this useful? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
Gregory Stark <stark@enterprisedb.com> writes: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: >> 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. > The only thing is that this has a semantic effect. It means users will > be able to call these functions from SQL directly. Are they safe to > allow this? Is this useful? No, no, and no, because there will still be at least one "internal" argument. I'm just suggesting that the argument positions that do correspond to ordinary SQL types should be declared that way, as an extra way of distinguishing these support functions from others for other opclasses. regards, tom lane