Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
> > "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> >> Uh, no. Function names for example are subject to search-path
> >> confusion.
>
> > Wait, are they? They are in PL languages but only because most
> > languages store their source code as text just as is happening here.
>
> Hmmm ... if you look at the current solution for default expressions
> for serial columns, ie nextval() on a regclass constant, it's pretty
> schema-safe. So we could imagine inventing a regconfig datatype that
> is the same sort of wrapper-over-OID. Then make the 2-parameter form
> of to_tsvector take that type instead of text.
Right, that's what I was getting at. I was confused about the trigger
issues, sorry about that.
> That seems like it'd fix the problem for expression indexes on
> to_tsvector calls, but I don't see how it fixes the problem for
> triggers. We don't have any clear path for making trigger arguments
> be anything but a list of strings.
Okay, trying to catch up here...
For the simple case of handling a single column, we've got expression
indexes as above.
For handling two or more columns, expression indexes don't work that
well, so that leaves triggers. There happens to be one utility
function provided for that purpose, tsvector_update_trigger(). This
trigger function needs its configuration as a (string) argument, and
is also the only one with this problem.
Is that correct?
If so, then it seems the question should really be: is this situation
of wanting to index multiple columns together, without even using
different ranks for them, so common that this trigger function belongs
in core? Maybe it shouldn't be there at all; instead have the docs
walk through creating a specialized trigger function. It doesn't get
rid of the schema-qualified names issue, but when you're writing PL
functions you need to deal with that anyway, tsearch or not.
And there's still contrib of course.
