On Mon, Jan 18, 2016 at 2:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Fixing the pg_proc entries in HEAD seems like no big deal, but some of
> the errors are in contrib modules. If we wanted to be really clean
> about that, we'd have to bump those modules' extension versions, which
> is a pain in the rear. Since this has no user-visible impact AFAICS
> (the support functions not being callable from SQL), I'm inclined to
> just fix the incorrect declarations in-place. I think it's sufficient
> if the contrib modules pass amvalidate checks in future, I don't feel
> a need to make existing installations pass.
>
> Any objections?
>
> regards, tom lane
>
This work (9ff60273e35cad6e9) seems have broken pg_upgrade when
tsearch2 is installed.
On an empty 9.4 instance with nothing but tsearch2 installed, using
HEAD's pg_upgrade gives this error:
pg_restore: creating OPERATOR CLASS "public.gin_tsvector_ops"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3037; 2616 19016
OPERATOR CLASS gist_tp_tsquery_ops jjanes
pg_restore: [archiver (db)] could not execute query: ERROR: function
gtsquery_consistent(internal, internal, integer, oid, internal) does
not exist
Command was: CREATE OPERATOR CLASS "gist_tp_tsquery_ops"
FOR TYPE "pg_catalog"."tsquery" USING "gist" AS
STORAGE bigint ,
OPE...
Cheers,
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
