Hi hackers,
In the process of trying to unify the various text/cstring conversions
in the backend, I came across some stuff that seemed weird in
pg_convert().
From src/backend/utils/mb/mbutils.c:345:
Datum
pg_convert(PG_FUNCTION_ARGS)
{
bytea *string = PG_GETARG_TEXT_P(0);
Is this
Brendan Jurd wrote:
Hi hackers,
In the process of trying to unify the various text/cstring conversions
in the backend, I came across some stuff that seemed weird in
pg_convert().
From src/backend/utils/mb/mbutils.c:345:
Datum
pg_convert(PG_FUNCTION_ARGS)
{
bytea *string =
Andrew Dunstan [EMAIL PROTECTED] writes:
We can and possibly should change the GETARG call, but the varlena types
are structurally equivalent, so it's not a mortal sin being committed here.
We *definitely* should change it --- the reason for having all those
variant macros in the first place
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
We can and possibly should change the GETARG call, but the varlena types
are structurally equivalent, so it's not a mortal sin being committed here.
We *definitely* should change it --- the reason for having all those
variant
Andrew Dunstan [EMAIL PROTECTED] writes:
I have changed it. The thing is, though, that this function not only
performs the convert() function but acts as the engine for convert_to()
and convert_from(). Those functions do some silent transformations, in
one case passing a text Datum as the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have changed it. The thing is, though, that this function not only
performs the convert() function but acts as the engine for convert_to()
and convert_from(). Those functions do some silent transformations, in
one case passing a
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm. One suggestion would be to have an internal function declared
as taking and returning struct varlena *, with a comment saying that
we depend on text and bytea both being compatible with this. All three
SQL-visible functions are
