Обсуждение: don't know whether nodes of type 719 are equal

Поиск
Список
Период
Сортировка

don't know whether nodes of type 719 are equal

От
Peter Eisentraut
Дата:
... yeah, me neither.

Hi all, I have an interesting one for you today. I'm writing a new \dd
command (one that actually works), and I have come across the following
situation:

SELECT DISTINCT a.aggname as "Name" FROM pg_aggregate a UNION ALL
SELECT DISTINCT p.proname as "Name" FROM pg_proc p UNION ALL
SELECT DISTINCT o.oprname as "Name" FROM pg_operator o UNION ALL
SELECT DISTINCT t.typname as "Name" FROM pg_type t UNION ALL
SELECT DISTINCT c.relname as "Name" FROM pg_class c
;

(It doesn't make much sense as it stands, but I have picked out the
offending parts.)

I get
NOTICE:  equal: don't know whether nodes of type 719 are equal

Actually, I get several of these. Depending on the number of select
clauses, I get 1 for the third, 2 for the 4th, 3 for the 5th, etc. So the
above query gives me 6 notices. A query with only two select clauses gives
me none.

Without the DISTINCTs everything goes fine.

Now this seems to have something to do with a lack of an equal operator
for the type "name", right? Interestingly enough, the type name has oid
19, whereas type 719 is "_circle", or what does the 719 refer to?

Thanks,Peter

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden




Re: [HACKERS] don't know whether nodes of type 719 are equal

От
Bruce Momjian
Дата:
I think someone changed the database schema.  Try cvs update then
initdb.  Could it be that the row of type circle is causing it?


I don't get that here, and 719 is certainly a strange number to be
getting

> ... yeah, me neither.
> 
> Hi all, I have an interesting one for you today. I'm writing a new \dd
> command (one that actually works), and I have come across the following
> situation:
> 
> SELECT DISTINCT a.aggname as "Name" FROM pg_aggregate a
>   UNION ALL
> SELECT DISTINCT p.proname as "Name" FROM pg_proc p
>   UNION ALL
> SELECT DISTINCT o.oprname as "Name" FROM pg_operator o
>   UNION ALL
> SELECT DISTINCT t.typname as "Name" FROM pg_type t
>   UNION ALL
> SELECT DISTINCT c.relname as "Name" FROM pg_class c
> ;
> 
> (It doesn't make much sense as it stands, but I have picked out the
> offending parts.)
> 
> I get
> NOTICE:  equal: don't know whether nodes of type 719 are equal
> 
> Actually, I get several of these. Depending on the number of select
> clauses, I get 1 for the third, 2 for the 4th, 3 for the 5th, etc. So the
> above query gives me 6 notices. A query with only two select clauses gives
> me none.
> 
> Without the DISTINCTs everything goes fine.
> 
> Now this seems to have something to do with a lack of an equal operator
> for the type "name", right? Interestingly enough, the type name has oid
> 19, whereas type 719 is "_circle", or what does the 719 refer to?
> 
> Thanks,
>     Peter
> 
> -- 
> Peter Eisentraut                  Sernanders vaeg 10:115
> peter_e@gmx.net                   75262 Uppsala
> http://yi.org/peter-e/            Sweden
> 
> 
> 
> ************
> 


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] don't know whether nodes of type 719 are equal

От
Oleg Bartunov
Дата:
I also got this message with UNION  and distinct. 
I've tested 6.5.2 and 6.5.3. Current (6.6 or 7.0 ?) works fine

select  distinct a.msg_id, c.status_set_date, c.title            from Message_Keyword_map a, messages c, keywords d
      where c.status_id =1 and d.name ~* 'sun'  and a.key_id=d.key_id            and c.msg_id=a.msg_id        union
  select distinct  a.msg_id, a.status_set_date, a.title            from messages a where a.status_id = 1 and a.title ~*
'sun';


NOTICE:  equal: don't know whether nodes of type 719 are equal
Oleg
This  is with postgres 6.5.3
On Sun, 17 Oct 1999, Bruce Momjian wrote:

> Date: Sun, 17 Oct 1999 15:57:52 -0400 (EDT)
> From: Bruce Momjian <maillist@candle.pha.pa.us>
> To: Peter Eisentraut <peter_e@gmx.net>
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] don't know whether nodes of type 719 are equal
> 
> I think someone changed the database schema.  Try cvs update then
> initdb.  Could it be that the row of type circle is causing it?
> 
> 
> I don't get that here, and 719 is certainly a strange number to be
> getting
> 
> > ... yeah, me neither.
> > 
> > Hi all, I have an interesting one for you today. I'm writing a new \dd
> > command (one that actually works), and I have come across the following
> > situation:
> > 
> > SELECT DISTINCT a.aggname as "Name" FROM pg_aggregate a
> >   UNION ALL
> > SELECT DISTINCT p.proname as "Name" FROM pg_proc p
> >   UNION ALL
> > SELECT DISTINCT o.oprname as "Name" FROM pg_operator o
> >   UNION ALL
> > SELECT DISTINCT t.typname as "Name" FROM pg_type t
> >   UNION ALL
> > SELECT DISTINCT c.relname as "Name" FROM pg_class c
> > ;
> > 
> > (It doesn't make much sense as it stands, but I have picked out the
> > offending parts.)
> > 
> > I get
> > NOTICE:  equal: don't know whether nodes of type 719 are equal
> > 
> > Actually, I get several of these. Depending on the number of select
> > clauses, I get 1 for the third, 2 for the 4th, 3 for the 5th, etc. So the
> > above query gives me 6 notices. A query with only two select clauses gives
> > me none.
> > 
> > Without the DISTINCTs everything goes fine.
> > 
> > Now this seems to have something to do with a lack of an equal operator
> > for the type "name", right? Interestingly enough, the type name has oid
> > 19, whereas type 719 is "_circle", or what does the 719 refer to?
> > 
> > Thanks,
> >     Peter
> > 
> > -- 
> > Peter Eisentraut                  Sernanders vaeg 10:115
> > peter_e@gmx.net                   75262 Uppsala
> > http://yi.org/peter-e/            Sweden
> > 
> > 
> > 
> > ************
> > 
> 
> 
> -- 
>   Bruce Momjian                        |  http://www.op.net/~candle
>   maillist@candle.pha.pa.us            |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> ************
> 

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83



Re: [HACKERS] don't know whether nodes of type 719 are equal

От
Tom Lane
Дата:
Peter Eisentraut <peter_e@gmx.net> writes:
> SELECT DISTINCT t.typname as "Name" FROM pg_type t
>   UNION ALL
> SELECT DISTINCT c.relname as "Name" FROM pg_class c
> ;
> (It doesn't make much sense as it stands, but I have picked out the
> offending parts.)

> I get
> NOTICE:  equal: don't know whether nodes of type 719 are equal

(consults include/nodes/nodes.h ... hmm, "SortClause" ...)

This is probably happening because UNION/INTERSECT processing tries
to simplify the node tree using cnfify(), which is really designed
to work on expressions not whole queries.  Ordinarily you can't get a
sort clause into a subclause of a UNION ... but I guess with DISTINCT
you can.  (I bet UNIONing things containing GROUP BY fails too,
since equal() doesn't know about GroupClause nodes either.)

A quick-fix answer is to extend equal(), of course, but I've been
wondering for a while why we are cnfify'ing UNION/INTERSECT trees
at all.  The odds of being able to simplify the tree that way seem
small, and what's worse is that UNION does *not* have the same
semantics as OR (eg, foo UNION foo should *not* be simplified to foo)
but cnfify doesn't know that.
        regards, tom lane


Re: [HACKERS] don't know whether nodes of type 719 are equal

От
Bruce Momjian
Дата:
> (consults include/nodes/nodes.h ... hmm, "SortClause" ...)
> 
> This is probably happening because UNION/INTERSECT processing tries
> to simplify the node tree using cnfify(), which is really designed
> to work on expressions not whole queries.  Ordinarily you can't get a
> sort clause into a subclause of a UNION ... but I guess with DISTINCT
> you can.  (I bet UNIONing things containing GROUP BY fails too,
> since equal() doesn't know about GroupClause nodes either.)
> 
> A quick-fix answer is to extend equal(), of course, but I've been
> wondering for a while why we are cnfify'ing UNION/INTERSECT trees
> at all.  The odds of being able to simplify the tree that way seem
> small, and what's worse is that UNION does *not* have the same
> semantics as OR (eg, foo UNION foo should *not* be simplified to foo)
> but cnfify doesn't know that.

My recollection is that cnfify is not called to simplify, but was
required at one point so you got the right output.  That may no longer
be the case, but I know it was at some point.  Before installed kqso,
the author tried to just skip cnfify, and the query with OR's didn't
work.  Of course, none of us understood cnfify(), so just scratched our
heads.


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] don't know whether nodes of type 719 are equal

От
Tatsuo Ishii
Дата:
> I also got this message with UNION  and distinct. 
> I've tested 6.5.2 and 6.5.3. Current (6.6 or 7.0 ?) works fine

Me too. Current works fine, but 6.5.2 not.
---
Tatsuo Ishii


Re: [HACKERS] don't know whether nodes of type 719 are equal

От
Bruce Momjian
Дата:
> > I also got this message with UNION  and distinct. 
> > I've tested 6.5.2 and 6.5.3. Current (6.6 or 7.0 ?) works fine
> 
> Me too. Current works fine, but 6.5.2 not.

Better than 6.5.* working and current failing.  :-)

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] don't know whether nodes of type 719 are equal

От
Tom Lane
Дата:
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> My recollection is that cnfify is not called to simplify, but was
> required at one point so you got the right output.  That may no longer
> be the case, but I know it was at some point.

For ordinary qual expressions, the only thing cnfify does that is
actually *necessary* for downstream processing is that it changes
the top-level boolean condition into an implicitly-ANDed list of
clauses.  That is, (AND A B ...) becomes (A B ...), anything else
becomes a singleton list ((X)).  So you could replace cnfify with
make_ands_implicit() and things would still work.  (I believe
Peter Andrews is presently getting useful work done with cnfify
lobotomized in more or less that fashion --- he's using queries
that expand unpleasantly with normal cnfify.)

I am not sure whether this is true for UNION/INTERSECT processing
though.  There are some really ugly kluges in UNION/INTERSECT, and
I don't think I understand all of its dependencies.
        regards, tom lane


Re: [HACKERS] don't know whether nodes of type 719 are equal

От
Bruce Momjian
Дата:
> I am not sure whether this is true for UNION/INTERSECT processing
> though.  There are some really ugly kluges in UNION/INTERSECT, and
> I don't think I understand all of its dependencies.

Yes, that code was not our finest hour.  :-)

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] don't know whether nodes of type 719 are equal

От
Tom Lane
Дата:
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> I also got this message with UNION  and distinct. 
>> I've tested 6.5.2 and 6.5.3. Current (6.6 or 7.0 ?) works fine

> Me too. Current works fine, but 6.5.2 not.

No, it's still there in current:

regression=> explain select distinct * from tenk1
regression-> union select distinct * from tenk1;
NOTICE:  equal: don't know whether nodes of type 719 are equal
NOTICE:  QUERY PLAN:
... etc ...

It might be a little harder to get in current.  I think that in
a fit of code beautification I rearranged _equalQuery so that the
sort/group clauses are tested later than they used to be.  You
won't see this notice if _equalQuery discovers that the query
nodes are non-identical before it gets to the sort specification.
Thus:

regression=> explain select distinct * from tenk1 t1      
regression-> union select distinct * from tenk1 t2; 
NOTICE:  QUERY PLAN:
... etc ...

This entirely equivalent query has different refnames in the rangetables
of the two subselects, which means equal() considers the nodes
non-identical; and the rangetable is checked by equalQuery before it
gets to the sort clause.  So the sort clauses are never compared.
Bingo, no message.

Being harder to get doesn't make it any less a bug, of course.
But I'm not especially concerned about it --- the query works,
the message is just noise; so I think we can live with it until
we get around to doing the major querytree redesign that we need
to do for subselects in FROM as well as some less pressing problems
like this one...
        regards, tom lane