From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Odd warning from pg_dump |
Date: | 2016-03-08 15:45:19 |
Message-ID: | 20160308154518.GN3127@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> In connection with a question on -general, I tried this:
>
> $ pg_dump -n '*' regression >regression.dump
> pg_dump: WARNING: typtype of data type "any" appears to be invalid
> pg_dump: WARNING: typtype of data type "anyarray" appears to be invalid
> pg_dump: WARNING: typtype of data type "anyelement" appears to be invalid
> pg_dump: WARNING: typtype of data type "anyenum" appears to be invalid
> pg_dump: WARNING: typtype of data type "anynonarray" appears to be invalid
> pg_dump: WARNING: typtype of data type "anyrange" appears to be invalid
> pg_dump: WARNING: typtype of data type "cstring" appears to be invalid
> pg_dump: WARNING: typtype of data type "event_trigger" appears to be invalid
> pg_dump: WARNING: typtype of data type "fdw_handler" appears to be invalid
> pg_dump: WARNING: typtype of data type "index_am_handler" appears to be invalid
> pg_dump: WARNING: typtype of data type "internal" appears to be invalid
> pg_dump: WARNING: typtype of data type "language_handler" appears to be invalid
> pg_dump: WARNING: typtype of data type "opaque" appears to be invalid
> pg_dump: WARNING: typtype of data type "pg_ddl_command" appears to be invalid
> pg_dump: WARNING: typtype of data type "record" appears to be invalid
> pg_dump: WARNING: typtype of data type "trigger" appears to be invalid
> pg_dump: WARNING: typtype of data type "tsm_handler" appears to be invalid
> pg_dump: WARNING: typtype of data type "void" appears to be invalid
> $
>
> The datatypes being complained of are evidently all the pseudo-types.
> I haven't looked into the code to figure out why this happens.
> The dump is produced anyway, so it's only a cosmetic issue, but seems
> probably worth fixing.
This is fixed in my changes to pg_dump, though I didn't expect you'd be
able to hit them in released versions and so hadn't been planning to
break it out.
This is the hunk for that particular change (line numbers are probably
off due to my other changes in the overall patch):
*************** dumpType(Archive *fout, TypeInfo *tyinfo
*** 8722,8727 ****
--- 8727,8743 ----
dumpRangeType(fout, tyinfo);
else if (tyinfo->typtype == TYPTYPE_PSEUDO && !tyinfo->isDefined)
dumpUndefinedType(fout, tyinfo);
+ else if (tyinfo->typtype == TYPTYPE_PSEUDO && tyinfo->isDefined &&
+ strncmp(tyinfo->dobj.namespace->dobj.name, "pg_catalog", 10) == 0)
+ /*
+ * skip defined pseudo-types in pg_catalog, they are special cases in
+ * the type system which are defined at initdb time only.
+ *
+ * Should a user manage to create one (which would require hand hacking
+ * the catalog, currently), throwing the below error seems entirely
+ * reasonable.
+ */
+ return;
else
write_msg(NULL, "WARNING: typtype of data type \"%s\" appears to be invalid\n",
tyinfo->dobj.name);
I can certainly look at committing that independently from the other
pg_dump changes that I'm working on.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Joseph Krogh | 2016-03-08 15:46:11 | Re: Exclude pg_largeobject form pg_dump |
Previous Message | Tom Lane | 2016-03-08 15:43:23 | Re: VS 2015 support in src/tools/msvc |