1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00

Fix contrib/pg_trgm to have smoother updates from 9.0.

Take care of some loose ends in the update-from-unpackaged script, and
apply some ugly hacks to ensure that it produces the same catalog state
as the fresh-install script.  Per discussion, this seems like a safer
plan than having two different catalog states that both call themselves
"pg_trgm 1.0", even if it's not immediately clear that the subtle
differences would ever matter.

Also, fix the stub function gin_extract_trgm() so that it works instead
of just bleating.  Needed because this function will get called during a
regular dump and reload, if there are any indexes using its opclass.
The user won't have an opportunity to update the extension till later,
so telling him to do so is unhelpful.
This commit is contained in:
Tom Lane
2011-02-17 15:03:30 -05:00
parent 3472a2b056
commit 4eb49db7ae
3 changed files with 83 additions and 15 deletions

View File

@ -29,14 +29,16 @@ Datum gin_trgm_consistent(PG_FUNCTION_ARGS);
/*
* This function can only be called if a pre-9.1 version of the GIN operator
* class definition is present in the catalogs (probably as a consequence
* of upgrade-in-place). Complain.
* of upgrade-in-place). Cope.
*/
Datum
gin_extract_trgm(PG_FUNCTION_ARGS)
{
ereport(ERROR,
(errmsg("GIN operator class for pg_trgm is out of date"),
errhint("Please drop and re-create the pg_trgm catalog entries.")));
if (PG_NARGS() == 3)
return gin_extract_value_trgm(fcinfo);
if (PG_NARGS() == 7)
return gin_extract_query_trgm(fcinfo);
elog(ERROR, "unexpected number of arguments to gin_extract_trgm");
PG_RETURN_NULL();
}