Re: [HACKERS] TCL_ARRAYS code in libpgtcl is pretty seriously broken
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] TCL_ARRAYS code in libpgtcl is pretty seriously broken |
Дата | |
Msg-id | 24323.907630779@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] TCL_ARRAYS code in libpgtcl is pretty seriously broken (Massimo Dal Zotto <dz@cs.unitn.it>) |
Ответы |
Re: [HACKERS] TCL_ARRAYS code in libpgtcl is pretty seriously broken
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: