> > > I agree that it would be better to *not* allow implicit coercions.
Given
> > > that, any preferences on function names? Are text_to_bytea() and
> > > bytea_to_text() too ugly?
> >
> > They're pretty ugly, but more importantly they're only suitable if we
> > have exactly one conversion function each way. If we have two, what
> > will we call the second one?
>
> Why not just stick these things into encode() and name them
> "my-cool-encoding" or whatever. There is no truly natural conversion
> between text and bytea, so encode/decode seem like the proper place.
>
(I'm sending directly to Peter, Tom, and Bruce because you were all involved
in this thread, and the list seems to be down)
Here's a patch for bytea string functions. As discussed:
text encode(bytea, 'escape')
bytea decode(text, 'escape')
to allow conversion bytea-text/text-bytea conversion. Also implemented
(SQL99 defines Binary Strings with all of these operators):
byteacat and "||" operator
substring
trim (only did trim(bytea, bytea) since there is no default trim character
for bunary per SQL99)
length (just aliased octet_length, which is correct for bytea, I think)
position
like and "~~" operator
not like and "!~~" operator
I think that's it.
Passes all regression tests. Based on the discussion, I did not create
functions to allow casting text-to-bytea or bytea-to-text -- it sounded like
we just want people to use encode/decode. I'm still planning to write
PQescapeBytea, but that will come later as a seperate patch. One operator
defined by SQL99, but not implemented here (or for text datatype, that I
could see) is the "overlay" function (modifies string argument by replacing
a substring given start and length with a replacement string). It sounds
useful -- any interest?
Review and comments much appreciated!
-- Joe
