Thread: Re: unknownin/out patch (was [HACKERS] PQescapeBytea is not
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. --------------------------------------------------------------------------- pgman wrote: > > Patch applied. Thanks. > > Catalog version updated. > > --------------------------------------------------------------------------- -- Bruce Momjian | http://candle.pha.pa.us pgman@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 Index: src/include/catalog/pg_proc.h =================================================================== RCS file: /cvsroot/pgsql/src/include/catalog/pg_proc.h,v retrieving revision 1.230 diff -c -r1.230 pg_proc.h *** src/include/catalog/pg_proc.h 24 Apr 2002 02:12:53 -0000 1.230 --- src/include/catalog/pg_proc.h 24 Apr 2002 03:05:35 -0000 *************** *** 237,245 **** DATA(insert OID = 108 ( scalargtjoinsel PGNSP PGUID 12 f t f t f s 3 701 "0 26 0" 100 0 0 100 scalargtjoinsel - _null_)); DESCR("join selectivity of > and related operators on scalar datatypes"); ! DATA(insert OID = 109 ( unknownin PGNSP PGUID 12 f t t i 1 f 705 "0" 100 0 0 100 unknownin - _null_)); DESCR("(internal)"); ! DATA(insert OID = 110 ( unknownout PGNSP PGUID 12 f t t i 1 f 23 "0" 100 0 0 100 unknownout - _null_ )); DESCR("(internal)"); DATA(insert OID = 112 ( text PGNSP PGUID 12 f t t t f i 1 25 "23" 100 0 0 100 int4_text - _null_ )); --- 237,245 ---- DATA(insert OID = 108 ( scalargtjoinsel PGNSP PGUID 12 f t f t f s 3 701 "0 26 0" 100 0 0 100 scalargtjoinsel - _null_)); DESCR("join selectivity of > and related operators on scalar datatypes"); ! DATA(insert OID = 109 ( unknownin PGNSP PGUID 12 f t t t f i 1 705 "0" 100 0 0 100 unknownin - _null_ )); DESCR("(internal)"); ! DATA(insert OID = 110 ( unknownout PGNSP PGUID 12 f t t t f i 1 23 "0" 100 0 0 100 unknownout - _null_ )); DESCR("(internal)"); DATA(insert OID = 112 ( text PGNSP PGUID 12 f t t t f i 1 25 "23" 100 0 0 100 int4_text - _null_ ));
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. -- Bruce Momjian | http://candle.pha.pa.us pgman@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 *** ./expected/opr_sanity.out Fri Apr 12 21:33:24 2002 --- ./results/opr_sanity.out Tue Apr 23 23:48:18 2002 *************** *** 198,205 **** (p1.pronargs = 2 AND p1.proargtypes[0] = prorettype AND p1.proargtypes[1] = 23))); oid | proname ! -----+--------- ! (0 rows) -- **************** pg_operator **************** -- Look for illegal values in pg_operator fields. --- 198,207 ---- (p1.pronargs = 2 AND p1.proargtypes[0] = prorettype AND p1.proargtypes[1] = 23))); oid | proname ! -----+------------ ! 109 | unknownin ! 110 | unknownout ! (2 rows) -- **************** pg_operator **************** -- Look for illegal values in pg_operator fields. ======================================================================
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, I am also seeing this failure on the opr_sanity checks.
Perhaps you should run regression tests before committing a patch,
rather than after.
regards, tom lane
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
Joe Conway <mail@joeconway.com> writes:
> ... I guess the question is whether
> or not unknownin/out should be marked proimplicit = 't' or not.
AFAIR there are no I/O routines that should be marked proimplicit = 't'.
We don't allow "C string" to be handled as part of the type system,
and until we do it doesn't make any sense to allow implicit conversions
to or from "C string".
The oprsanity tests are still a few bricks shy of a load w.r.t. the
recent pg_proc and namespace changes --- I hope to add more checks soon.
regards, tom lane