"Trevor Talbot" <[EMAIL PROTECTED]> writes:
> Currently you can schema-qualify objects where you need to, to avoid
> issues with search_path subversion. If it's impossible to
> schema-qualify tsearch configs now, when schema support is later added
> it suddenly exposes everyone to risks that didn't exist before, and
> requires manual changes to fix.
True. I thought of another counter-argument as well: we use schemas
not only so that pg_dump can tell user from system objects, but for
permissions purposes. If TS configs don't live in schemas then there is
no structure for controlling who may create one. A fairly standard
requirement is to be able to prevent someone from creating any non-temp
objects (or not even those), and right now you do it by revoking create
rights in the public schema, and/or permissions to create new schemas.
We'd need some other kluge for non-schema-ified TS objects.
So let's go back to the "regconfig" idea. If we invent such a type, and
make the 2-parameter forms of to_tsvector et al take that instead of
just text for the config name, then I think we have fixed things for the
expression index case. (There are also other benefits, eg a command
applying one of these functions on many rows wouldn't have to do a
name-based config lookup each time.) The problem is with the trigger
approach.
As my copy of the patch currently stands, there are two built-in trigger
functions, tsvector_update_trigger and tsvector_update_trigger_column.
The first expects trigger arguments
name of tsvector col, name of tsconfig to use, name(s) of text col(s)
and the second
name of tsvector col, name of tsconfig col, name(s) of text col(s)
that is, the tsconfig name is stored in a text column. We could fix
the second form by changing it to expect the tsconfig column to be of
type regconfig. The first form is a bit more problematic. I can see
two approaches: either specify both the schema and the tsconfig name,
as two separate arguments, or keep it one argument but insist that
the content of the argument be an explicitly-qualified name. The
second way seems a bit klugier when considered in isolation, but I think
I like it better, because there would be a natural migration path to
treating the argument as being of type regconfig when and if we get
around to having real types for trigger arguments. (Which I think is
a good idea, btw, just not for 8.3.)
This looks fairly do-able --- a regconfig data type is no problem,
should be able to whip it up with an hour or two of cutting and pasting
code from one of the existing OID alias types. And the other changes
seem minor. (Note: offhand I don't see a need for "reg" types for
parsers, dictionaries, or templates, since none of those are referenced
directly in queries.)
Thoughts?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
