Odd warning from pg_dump

* Tom Lane (tgl@sss.pgh.pa.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

Stephen Frost <sfrost@snowman.net> writes:

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

pg_dump: WARNING: typtype of data type "any" appears to be invalid

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.

Oh, this was with HEAD; I've not checked it in released versions.

regards, tom lane

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

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Stephen Frost <sfrost@snowman.net> writes:

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

pg_dump: WARNING: typtype of data type "any" appears to be invalid

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.

Oh, this was with HEAD; I've not checked it in released versions.

Using your "-n '*'", I suspect you'd be able to hit it in released
versions also.

I think the real question is if "-n '*'" should still exclude
'pg_catalog'. Fixing the issue with defined pseudo types is wonderful,
but aren't you going to end up with a dump you can't restore,
regardless?

Thanks!

Stephen

Stephen Frost <sfrost@snowman.net> writes:

I think the real question is if "-n '*'" should still exclude
'pg_catalog'. Fixing the issue with defined pseudo types is wonderful,
but aren't you going to end up with a dump you can't restore,
regardless?

Yeah, perhaps so. The thread on -general has also produced the
information that pg_dump -t '*' tries to dump system catalogs as if
they were user tables, which is another pretty useless bit of behavior.
So maybe we should drop the hunk you've got there (which frankly seems a
bit of a kluge) and instead hot-wire things so that stuff in pg_catalog
is excluded even if it would otherwise match the inclusion lists.

regards, tom lane

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

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Stephen Frost <sfrost@snowman.net> writes:

I think the real question is if "-n '*'" should still exclude
'pg_catalog'. Fixing the issue with defined pseudo types is wonderful,
but aren't you going to end up with a dump you can't restore,
regardless?

Yeah, perhaps so. The thread on -general has also produced the
information that pg_dump -t '*' tries to dump system catalogs as if
they were user tables, which is another pretty useless bit of behavior.

Indeed.

So maybe we should drop the hunk you've got there (which frankly seems a
bit of a kluge) and instead hot-wire things so that stuff in pg_catalog
is excluded even if it would otherwise match the inclusion lists.

An idealistic viewpoint might be that we should provide a way to
actually create defined pseudo-types and then make pg_dump work with
them, but I have a hard time seeing why that would be worth the effort.
One might also argue that we should have a way of dealing with every
type of object which exists and defined psuedo-types seem to be the only
thing left out.

I agree that it seems like the best idea is to just hot-wire pg_dump to
exclude pg_catalog, though I'm inclined to suggest that we just exclude
it from pattern matches. We know that objects sometimes end up in
pg_catalog which aren't really supposed to be there and there might be
other reasons to want to dump it out, so having 'pg_dump -n pg_catalog'
still do its best to dump out what's been asked for seems reasonable.

Thanks!

Stephen

Tom Lane wrote:

Stephen Frost <sfrost@snowman.net> writes:

I think the real question is if "-n '*'" should still exclude
'pg_catalog'. Fixing the issue with defined pseudo types is wonderful,
but aren't you going to end up with a dump you can't restore,
regardless?

Yeah, perhaps so. The thread on -general has also produced the
information that pg_dump -t '*' tries to dump system catalogs as if
they were user tables, which is another pretty useless bit of behavior.
So maybe we should drop the hunk you've got there (which frankly seems a
bit of a kluge) and instead hot-wire things so that stuff in pg_catalog
is excluded even if it would otherwise match the inclusion lists.

Not sure that's reasonable. We have at least one extension in contrib
that creates objects in pg_catalog. ISTM that's enough precedent that
more could be created in the future. (Now of course extensions get
special treatment anyway, but my point is that there's no prohibition
against creating objects in pg_catalog.)

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Tom Lane wrote:

So maybe we should drop the hunk you've got there (which frankly seems a
bit of a kluge) and instead hot-wire things so that stuff in pg_catalog
is excluded even if it would otherwise match the inclusion lists.

Not sure that's reasonable. We have at least one extension in contrib
that creates objects in pg_catalog. ISTM that's enough precedent that
more could be created in the future. (Now of course extensions get
special treatment anyway, but my point is that there's no prohibition
against creating objects in pg_catalog.)

True, and given the lack of prior complaints, it might be better to
leave well enough alone here. What the -general thread was actually
suggesting is that pg_dump needs a way to forcibly omit blobs; the
question about behavior of the pattern-match switches was a sideshow.

regards, tom lane

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