Timespan_div misbehaving?
Hi,
When I try on current:
abr=> select sum(endt-begt-pausen)/count(*)::float8 from tage;
ERROR: Unable to identify an operator '/' for types 'timespan' and 'float8'
You will have to retype this query using an explicit cast
but:
abr=> \df
...
timespan |timespan_div |timespan float8 |divide
...
Why? Directly used I get:
abr=> select timespan_div(sum(endt-begt-pausen),count(*)::float8) from tage;
timespan_div
-----------------------------
@ 11 hours 24 mins 34.79 secs
(1 row)
It seems that an entry for '/' is defined:
grep timespan_div catalog/*.bki*
...
catalog/local1_template1.bki.source:insert OID = 1585 ( "/" PGUID 0 b t f 1186
1186 1186 0 0 0 0 timespan_div - - )
...
OR are the three 1186's wrong?
Shouldn't at least the second input type be 701?
Any clues?
Bye!
----
Michael Reifenberger
Plaut Software GmbH, R/3 Basis
Michael Reifenberger <root@nihil.plaut.de> writes:
catalog/local1_template1.bki.source:insert OID = 1585 ( "/" PGUID 0 b t f 1186
1186 1186 0 0 0 0 timespan_div - - )
OR are the three 1186's wrong?
Shouldn't at least the second input type be 701?
I think you are right --- the only timespan_div I can find in the source
code is TimeSpan *timespan_div(TimeSpan *span1, float8 *arg2) in adt/dt.c.
It looks like the entry for it in pg_proc is right, but the one in
pg_operator is wrong.
Hmm, a whole new class of cross-checks that opr_sanity ought to make ;-)
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofMon8Mar1999093305+0100Pine.BSF.4.05.9903080926020.20224-100000@nihil.plaut.de | Resolved by subject fallback
I said:
It looks like the entry for it in pg_proc is right, but the one in
pg_operator is wrong.Hmm, a whole new class of cross-checks that opr_sanity ought to make ;-)
Indeed, applying a mechanical cross-check was fruitful ... I found four
dozen pg_operator entries that disagree with the corresponding pg_proc
entries:
QUERY: SELECT p1.oid, p1.oprname, p2.oid, p2.proname
FROM pg_operator AS p1, pg_proc AS p2
WHERE p1.oprcode = p2.oid AND
p1.oprkind = 'b' AND
(p2.pronargs != 2 OR
p1.oprresult != p2.prorettype OR
(p1.oprleft != p2.proargtypes[0] AND p2.proargtypes[0] != 0) OR
(p1.oprright != p2.proargtypes[1] AND p2.proargtypes[1] != 0));
oid|oprname| oid|proname
----+-------+----+-------------
15|= | 852|int48eq
36|<> | 853|int48ne
37|< | 854|int48lt
76|> | 855|int48gt
80|<= | 856|int48le
82|>= | 857|int48ge
532|= | 158|int24eq
533|= | 159|int42eq
534|< | 160|int24lt
535|< | 161|int42lt
536|> | 162|int24gt
537|> | 163|int42gt
538|<> | 164|int24ne
539|<> | 165|int42ne
540|<= | 166|int24le
541|<= | 167|int42le
542|>= | 168|int24ge
543|>= | 169|int42ge
609|< | 66|int4lt
610|> | 147|int4gt
611|<= | 149|int4le
612|>= | 150|int4ge
626|!!= |1285|int4notin
974||| |1258|textcat
979||| |1258|textcat
1055|~ |1254|textregexeq
1056|!~ |1256|textregexne
1063|~ |1254|textregexeq
1064|!~ |1256|textregexne
1211|~~ | 850|textlike
1212|!~~ | 851|textnlike
1213|~~ | 850|textlike
1214|!~~ | 851|textnlike
1232|~* |1238|texticregexeq
1233|!~* |1239|texticregexne
1234|~* |1238|texticregexeq
1235|!~* |1239|texticregexne
1522|<-> |1476|dist_pc
1585|/ |1326|timespan_div
820|= | 920|network_eq
821|<> | 925|network_ne
822|< | 921|network_lt
823|<= | 922|network_le
824|> | 923|network_gt
825|>= | 924|network_ge
826|<< | 927|network_sub
827|<<= | 928|network_subeq
828|>> | 929|network_sup
1004|>>= | 930|network_supeq
(49 rows)
Some of these are quasi-legitimate cases (like both "text" and "varchar"
entries for one operator --- is that really necessary?). Quite a few
seem to be real bugs. Working on fixing them now.
If I can figure out how to deal with the binary-equivalent cases
automatically, will commit an extension of opr_sanity regress test to
detect such mistakes in future.
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofMon08Mar1999102129-05006342.920906489@sss.pgh.pa.us | Resolved by subject fallback
I said:
It looks like the entry for it in pg_proc is right, but the one in
pg_operator is wrong.Hmm, a whole new class of cross-checks that opr_sanity ought to make ;-)
Indeed, applying a mechanical cross-check was fruitful ... I found four
dozen pg_operator entries that disagree with the corresponding pg_proc
entries:
Tom, would you please take the pg/include/catalog/*.sql files and merge
them into the regression sanity checks? They should be in there too.
You can remove them once you have moved them over.
--
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