When the JDBC driver tries to query the information schema running against
cvs head, it gets an assertion failure. The query in question is the
ugly:

SELECT NULL AS TABLE_CAT, n.nspname AS TABLE_SCHEM, c.relname AS
TABLE_NAME, CASE n.nspname LIKE 'pg\\_%' OR n.nspname =
'information_schema' WHEN true THEN CASE WHEN n.nspname = 'pg_catalog'
OR n.nspname = 'information_schema' THEN CASE c.relkind WHEN 'r'
THEN 'SYSTEM TABLE' WHEN 'v' THEN 'SYSTEM VIEW' WHEN 'i' THEN
'SYSTEM INDEX' ELSE NULL END WHEN n.nspname = 'pg_toast'
THEN CASE c.relkind WHEN 'r' THEN 'SYSTEM TOAST TABLE'
WHEN 'i' THEN 'SYSTEM TOAST INDEX' ELSE NULL
END ELSE CASE c.relkind WHEN 'r' THEN 'TEMPORARY TABLE'
WHEN 'i' THEN 'TEMPORARY INDEX' ELSE NULL
END END WHEN false THEN CASE c.relkind WHEN 'r' THEN 'TABLE'
WHEN 'i' THEN 'INDEX' WHEN 'S' THEN 'SEQUENCE' WHEN 'v' THEN
'VIEW' ELSE NULL END ELSE NULL END AS TABLE_TYPE, d.description
AS REMARKS FROM pg_catalog.pg_namespace n, pg_catalog.pg_class c LEFT
JOIN pg_catalog.pg_description d ON (c.oid = d.objoid AND d.objsubid = 0)
LEFT JOIN pg_catalog.pg_class dc ON (d.classoid=dc.oid AND
dc.relname='pg_class') LEFT JOIN pg_catalog.pg_namespace dn ON
(dn.oid=dc.relnamespace AND dn.nspname='pg_catalog') WHERE c.relnamespace
= n.oid AND c.relname LIKE 'testmetadat%' AND (false OR ( c.relkind =
'r' AND n.nspname NOT LIKE 'pg\\_%' AND n.nspname <> 'information_schema'
) ) ORDER BY TABLE_TYPE,TABLE_SCHEM,TABLE_NAME


FailedAssertion("!(!and_clause((Node *) clause))", File:
"restrictinfo.c", Line: 66)

#0 0x40101561 in kill () from /lib/libc.so.6
#1 0x40101305 in raise () from /lib/libc.so.6
#2 0x40102828 in abort () from /lib/libc.so.6
#3 0x0820fd7c in ExceptionalCondition (
conditionName=0x6 <Address 0x6 out of bounds>,
errorType=0x822bf31 "FailedAssertion", fileName=0x40207290 "\022",
lineNumber=0) at assert.c:46
#4 0x0816cb13 in make_restrictinfo (clause=0x8392670,
is_pushed_down=1 '\001', valid_everywhere=1 '\001') at
restrictinfo.c:73
#5 0x08164c69 in distribute_qual_to_rels (root=0x8372b34,
clause=0x8392670,
is_pushed_down=1 '\001', isdeduced=0 '\0', outerjoin_nonnullable=0x0,
qualscope=0x8393970) at initsplan.c:509
#6 0x08164a7b in distribute_quals_to_rels (root=0x8372b34,
jtnode=0x838cbe0)
at initsplan.c:226
#7 0x0816569e in query_planner (root=0x8372b34, tlist=0x0,
tuple_fraction=0,
cheapest_path=0xbffff100, sorted_path=0xbffff104) at planmain.c:136
#8 0x08166397 in grouping_planner (parse=0x8372b34, tuple_fraction=0)
at planner.c:898
#9 0x08165bee in subquery_planner (parse=0x8372b34, tuple_fraction=0)
at planner.c:315
#10 0x08165889 in planner (parse=0x8372b34, isCursor=0 '\0',
cursorOptions=0)
at planner.c:119
#11 0x081a0d2f in pg_plan_query (querytree=0x8372b34) at postgres.c:588
---Type <return> to continue, or q <return> to quit---
#12 0x081a0dc7 in pg_plan_queries (querytrees=0x838cc34, needSnapshot=0
'\0')
at postgres.c:655
#13 0x081a0fab in exec_simple_query (
query_string=0x836089c "SELECT NULL AS TABLE_CAT, n.nspname AS
TABLE_SCHEM, c.relname AS TABLE_NAME, CASE n.nspname LIKE 'pg\\\\_%' OR
n.nspname = 'information_schema' WHEN true THEN CASE \tWHEN n.nspname =
'pg_catalog' OR n."...)
at postgres.c:813
#14 0x081a3360 in PostgresMain (argc=4, argv=0x82f9d88,
username=0x82f9d50 "test") at postgres.c:2843
#15 0x081776e3 in BackendRun (port=0x8306d08) at postmaster.c:2622
#16 0x08176f53 in BackendStartup (port=0x8306d08) at postmaster.c:2267
#17 0x081753d8 in ServerLoop () at postmaster.c:1141
#18 0x08174cb5 in PostmasterMain (argc=3, argv=0x82f9ad8) at
postmaster.c:904
#19 0x08142347 in main (argc=3, argv=0xbffffa94) at main.c:228



---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Kris Jurka <books (AT) ejurka (DOT) com> writes:
Duplicated here, will fix.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> writes:
Is it worth including some variant of this query in the regression
tests?

(Not to catch this particular bug appearing in the future, but merely
to exercise a fair bit of the planner.)

-Neil


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Mon, 12 Jan 2004, Neil Conway wrote:

Well this query is part of the JDBC driver regression test so it will
certainly get run from time to time.

Kris Jurka


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Neil Conway <neilc (AT) samurai (DOT) com> writes:
The information schema itself could perhaps use some regression tests.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly