Re: Bug in UTF8-Validation Code?

I wrote: 
>
> The escape processing is actually done in the lexer in the case of 
> literals. We have to allow for bytea literals there too, regardless of 
> encoding. The lexer naturally has no notion of the intended 
> destination of the literal, So we need to defer the validity check to 
> the *in functions for encoding-aware types. And it as Tom has noted, 
> COPY does its own escape processing but does it before the transcoding.
>
> So ISTM that any solution other than something like I have proposed 
> will probably involve substantial surgery.

Below is a list of the input routines in the adt directory, courtesy of 
grep.

I'm thinking we will need to put checks in:
   varcharin   bpcharin   textin   unknownin (?)   namein (?)

Any others?

cheers

andrew


acl.c:aclitemin
bool.c:boolin
char.c:charin
date.c:timetypmodin
date.c:timetztypmodin
float.c:dasin
float.c:dsin
nabstime.c:abstimein
nabstime.c:reltimein
nabstime.c:tintervalin
name.c:namein
not_in.c:oidnotin
numeric.c:numerictypmodin
oid.c:oidin
oid.c:oidvectorin
regproc.c:regprocin
regproc.c:regprocedurein
regproc.c:regoperin
regproc.c:regoperatorin
regproc.c:regclassin
regproc.c:regtypein
tid.c:tidin
timestamp.c:timestamptypmodin
timestamp.c:timestamptztypmodin
timestamp.c:intervaltypmodin
varbit.c:bittypmodin
varbit.c:varbittypmodin
varchar.c:bpcharin
varchar.c:bpchartypmodin
varchar.c:varcharin
varchar.c:varchartypmodin
varlena.c:byteain
varlena.c:textin
varlena.c:unknownin
xid.c:xidin
xid.c:cidin