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 ,



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to