Massimo Dal Zotto <dz@cs.unitn.it> writes:
>> [ my gripes about TCL_ARRAYS code snipped ]
> I wrote this code and used it for two years without any problem. All
> the bugs you mentioned disappear if you use the proper string output
> functions which C-like escapes (code in contrib/string-io).
Well, not the bug involving overwriting libpq's PGresult storage.
But still, this explains a good deal.
I guess my gripe here is that the TCL_ARRAYS option is enabled *by
default* in the Postgres distribution, but the code does not work
properly unless one plugs in a contrib function in the backend
(and if the connection between the two is documented anywhere, I sure
didn't see it). This is not a reasonable default setup.
As a short-term fix I suggest that we just turn off TCL_ARRAYS in
the distributed config.h.in --- does that sound reasonable to you?
In the longer term, there needs to be some way of applying the
TCL_ARRAYS conversion code only when your contrib stuff is being used.
Backing the conversion code out of pg_result and making it a separate
function might do, but that is a low-tech solution that puts the
responsibility on the application programmer to combine the right bits
of frontend and backend functionality. Perhaps someone can think of a
better way?
Ultimately I would like the text I/O functions to be completely 8-bit
clean and able to deal with arbitrary byte strings. That is not
something we can hope to shoehorn into 6.4, though.
regards, tom lane