Thread: Bytea binary compatible
Here is a patch to make bytea binary compatible with other text data types. Comments? -- 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/backend/parser/parse_coerce.c =================================================================== RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/parser/parse_coerce.c,v retrieving revision 2.58 diff -c -r2.58 parse_coerce.c *** src/backend/parser/parse_coerce.c 2001/06/19 22:39:11 2.58 --- src/backend/parser/parse_coerce.c 2001/06/23 14:21:09 *************** *** 470,475 **** --- 470,476 ---- case (CHAROID): case (NAMEOID): + case (BYTEAOID): case (BPCHAROID): case (VARCHAROID): case (TEXTOID): *************** *** 614,619 **** --- 615,621 ---- result = VARCHAROID; break; + case (BYTEAOID): case (VARCHAROID): result = TEXTOID; break; *************** *** 708,713 **** --- 710,716 ---- case (CHAROID): switch (*arg2) { + case (BYTEAOID): case (BPCHAROID): case (VARCHAROID): case (TEXTOID): *************** *** 772,777 **** --- 775,781 ---- case (CHAROID): switch (*arg2) { + case (BYTEAOID): case (BPCHAROID): case (VARCHAROID): case (TEXTOID): Index: src/backend/parser/parse_target.c =================================================================== RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/parser/parse_target.c,v retrieving revision 1.67 diff -c -r1.67 parse_target.c *** src/backend/parser/parse_target.c 2001/05/21 18:42:08 1.67 --- src/backend/parser/parse_target.c 2001/06/23 14:21:09 *************** *** 56,62 **** expr = transformExpr(pstate, node, EXPR_COLUMN_FIRST); if (IsA(expr, Ident) && ((Ident *)expr)->isRel) ! elog(ERROR,"You can't use relation names alone in the target list, try relation.*."); type_id = exprType(expr); type_mod = exprTypmod(expr); --- 56,62 ---- expr = transformExpr(pstate, node, EXPR_COLUMN_FIRST); if (IsA(expr, Ident) && ((Ident *)expr)->isRel) ! elog(ERROR,"You can't use relation names alone in the target list, try relation.*."); type_id = exprType(expr); type_mod = exprTypmod(expr); *************** *** 311,317 **** * string hacks to get transparent conversions w/o explicit * conversions */ ! else if ((attrtype == BPCHAROID) || (attrtype == VARCHAROID)) { Oid text_id = TEXTOID; --- 311,319 ---- * string hacks to get transparent conversions w/o explicit * conversions */ ! else if (attrtype == BPCHAROID || ! attrtype == VARCHAROID || ! attrtype == BYTEAOID) { Oid text_id = TEXTOID; Index: src/include/parser/parse_coerce.h =================================================================== RCS file: /home/projects/pgsql/cvsroot/pgsql/src/include/parser/parse_coerce.h,v retrieving revision 1.29 diff -c -r1.29 parse_coerce.h *** src/include/parser/parse_coerce.h 2001/06/19 22:39:12 1.29 --- src/include/parser/parse_coerce.h 2001/06/23 14:21:14 *************** *** 46,51 **** --- 46,52 ---- || ((t) == BPCHAROID) \ || ((t) == VARCHAROID) \ || ((t) == TEXTOID) \ + || ((t) == BYTEAOID) \ || ((t) == INT4OID) \ || ((t) == INT8OID) \ || ((t) == FLOAT8OID) \ *************** *** 85,94 **** --- 86,101 ---- #define IS_BINARY_COMPATIBLE(a,b) \ (((a) == BPCHAROID && (b) == TEXTOID) \ || ((a) == BPCHAROID && (b) == VARCHAROID) \ + || ((a) == BPCHAROID && (b) == BYTEAOID) \ || ((a) == VARCHAROID && (b) == TEXTOID) \ || ((a) == VARCHAROID && (b) == BPCHAROID) \ + || ((a) == VARCHAROID && (b) == BYTEAOID) \ || ((a) == TEXTOID && (b) == BPCHAROID) \ || ((a) == TEXTOID && (b) == VARCHAROID) \ + || ((a) == TEXTOID && (b) == BYTEAOID) \ + || ((a) == BYTEAOID && (b) == BPCHAROID) \ + || ((a) == BYTEAOID && (b) == VARCHAROID) \ + || ((a) == BYTEAOID && (b) == TEXTOID) \ || ((a) == OIDOID && (b) == INT4OID) \ || ((a) == OIDOID && (b) == REGPROCOID) \ || ((a) == INT4OID && (b) == OIDOID) \
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here is a patch to make bytea binary compatible with other text data
> types. Comments?
No way! Unless you propose to make the text types null-safe (which
would mean such nontrivial projects as replacing strcoll()).
The fact that the storage formats are both struct varlena does not
mean that these types are interchangeable. I fail to see where it'd
be a good idea to mark them binary-compatible, even if there weren't
serious implementation issues.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Here is a patch to make bytea binary compatible with other text data > > types. Comments? > > No way! Unless you propose to make the text types null-safe (which > would mean such nontrivial projects as replacing strcoll()). > > The fact that the storage formats are both struct varlena does not > mean that these types are interchangeable. I fail to see where it'd > be a good idea to mark them binary-compatible, even if there weren't > serious implementation issues. OK, code backed out. If the storage formats are the same, doesn't that make them binary compatibile. I know the NULL issue though. I think I see what you mean, that a text function can't operate on a bytea field. -- 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
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, code backed out. If the storage formats are the same, doesn't that > > make them binary compatibile. > > No, because one allows nulls and the other doesn't. If you disregard > what are legal values and what aren't, then every pair of varlena > datatypes we have could be called "binary compatible". > > More to the point, though, why *should* they be marked binary > compatible? I saw no compelling reason advanced for it, and I can see a > couple of compelling reasons not to. Every binary-compatible pairing is > another hole in our type system, another opportunity for unexpected > behavior. We shouldn't add them on whims. Especially we shouldn't add > them for datatypes that aren't even of the same family. bytea isn't for > storage of textual data, and so it makes little sense to allow > application of textual operations to it. I have no idea why the user wanted it. I suppose it was so he could pass text/varchar to bytea and back again. Seems he has to convert it, which makes sense about the NULLs. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, code backed out. If the storage formats are the same, doesn't that
> make them binary compatibile.
No, because one allows nulls and the other doesn't. If you disregard
what are legal values and what aren't, then every pair of varlena
datatypes we have could be called "binary compatible".
More to the point, though, why *should* they be marked binary
compatible? I saw no compelling reason advanced for it, and I can see a
couple of compelling reasons not to. Every binary-compatible pairing is
another hole in our type system, another opportunity for unexpected
behavior. We shouldn't add them on whims. Especially we shouldn't add
them for datatypes that aren't even of the same family. bytea isn't for
storage of textual data, and so it makes little sense to allow
application of textual operations to it.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, code backed out. If the storage formats are the same, doesn't that > > make them binary compatibile. Actually, I didn't mean to even apply the bytea patch I backed out. It accidentally got when I applied RESET ALL and I only realized it later. I had the diff in a separate file so it was easy to back out. -- 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