v9.3.0: bug with pgdump -s?
(Using the new PostgreSQL v9.3.0)
I did a schema-only dump of the 'pg_catalog' schema in the hopes to
study how the built-in OPERATOR CLASSes are defined.
Doing so output a few warnings:
$ [pg930] pg_dump -s -n pg_catalog template1 > /tmp/pg_catalog.sql
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 "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 "record" appears to be invalid
pg_dump: WARNING: typtype of data type "trigger" appears to be invalid
pg_dump: WARNING: typtype of data type "void" appears to be invalid
Additionally, the operator classes seem to be incomplete in pg_dump's
output:
CREATE OPERATOR CLASS box_ops
DEFAULT FOR TYPE box USING gist AS
;
...
CREATE OPERATOR CLASS text_ops
DEFAULT FOR TYPE text USING btree AS
;
I'd expect them to be fully spec'd with OPERATOR, FUNCTION, and STORAGE
arguments.
Am I expecting too much against 'pg_catalog' or is something bugged?
eric
PROPRIETARY AND COMPANY CONFIDENTIAL COMMUNICATIONS
The information contained in this communication is intended only for
the use of the addressee. Any other use is strictly prohibited.
Please notify the sender if you have received this message in error.
This communication is protected by applicable legal privileges and is
company confidential.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 2013-09-15 12:01:29 -0400, Eric B. Ridge wrote:
Am I expecting too much against 'pg_catalog' or is something bugged?
Yes, I think you do expect too much. It'd perhaps be nice to give a
nicer error message, but some of the stuff (like the pseudotypes you see
warnings about here) doesn't fully follow the public rules.
The likely reason you're seing the problem with the opclasses being
output incompletely is that internal entries don't all have full
dependency information.
What did you actually try to find out?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 09/15/2013 02:11 PM, Andres Freund wrote:
What did you actually try to find out? Greetings, Andres Freund
I was just trying to mentally sync up
http://www.postgresql.org/docs/9.3/static/xindex.html with (more)
concrete examples. Investigating pg_catalog seemed like the obvious
choice. Too bad.
eric
PROPRIETARY AND COMPANY CONFIDENTIAL COMMUNICATIONS
The information contained in this communication is intended only for
the use of the addressee. Any other use is strictly prohibited.
Please notify the sender if you have received this message in error.
This communication is protected by applicable legal privileges and is
company confidential.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 2013-09-15 15:24:57 -0400, Eric B. Ridge wrote:
On 09/15/2013 02:11 PM, Andres Freund wrote:
What did you actually try to find out? Greetings, Andres Freund
I was just trying to mentally sync up
http://www.postgresql.org/docs/9.3/static/xindex.html with (more) concrete
examples. Investigating pg_catalog seemed like the obvious choice. Too
bad.
Try looking at contrib/btree_gist or such.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general