Bruce Momjian wrote:
> Bruce Momjian wrote:
>
>>OK, I have had to apply this additional patch to fix a fmgr.c failure.
>>Would someone please verify that the additional columns I added have the
>>correct values. I think this was needed because there were other
>>changes to include/catalog/pg_proc.h in this area.
>>
> OK, I am also seeing this failure on the opr_sanity checks. I can't
> figure out whether it is OK that a unknown conversion function fails
> this test.
>
It looks like this is due to proimplicit which was added on 4/11/02
while this patch was created on 4/7/02. I guess the question is whether
or not unknownin/out should be marked proimplicit = 't' or not. If it
*does* need to be true, what needs to be done to pass the regression?
Here's the failing test in opr_sanity.out:
If a proc is marked as an implicit cast, then it should be something
that the system might actually use as a cast function: name same as the
name of its output type, and either one arg that's a different type, or
two args where the first is the same as the output type and the second
is int4.
SELECT p1.oid, p1.proname
FROM pg_proc as p1
WHERE p1.proimplicit AND
(NOT EXISTS (SELECT 1 FROM pg_type t WHERE t.oid = p1.prorettype AND
t.typname = p1.proname) OR
NOT ((p1.pronargs = 1 AND p1.proargtypes[0] != prorettype) OR
(p1.pronargs = 2 AND p1.proargtypes[0] = prorettype AND
p1.proargtypes[1] = 23)));
oid | proname
-----+---------
(0 rows)
Joe