Closed GitMensch closed 1 year ago
Note: the result of using VARRAW
in PostgreSQL with citpgsql seems to be actually a byte parameter instead of a text one, the pgsql log shows - only for fields that are VARRAW
:
DETAIL: parameters: $1 = '\x42204b20', $2 = '319331842'
(with $1 being much longer in the real log).
Allowing a USAGE
that internally either uses a "binary parameter binding" (instead of a text one) or manually encodes / decodes (much worse because of additional time needed on both ends) would also work around #125.
I did not found anything on this in the ProCOB or PG-ecpg docs, so this may be specific to citpgsql (but it seems that esql-oc also supports that in general).
From citpgsql docs they have the following varying group usages:
VARCHAR
andLONG VARCHAR
--LEN
defined asPIC S9(4) COMP-5
, used for "text, or binary fields, possible storage conversion, and trim" [I personally would tend to haveLONG
always have a 4byte length, but citpgsql does not agree with me here]VARYING
--LEN
defined asPIC S9(4) COMP-5
, used for "text, or binary fields, possible storage conversion, and trim"VARRAW
andLONG VARRAW
--LEN
defined asPIC S9(4) COMP-5
, used for "binary fields, no storage conversion"While this is, in general, related to #54; I suggest to - for now - alias
VARRAW
toVARYING
as this would allow to preprocess sources written for citpgsql and (at least by default) we also have a generation of a 4-byte length field.