Re: [HACKERS] TCL_ARRAYS code in libpgtcl is pretty seriously broken
От | Massimo Dal Zotto |
---|---|
Тема | Re: [HACKERS] TCL_ARRAYS code in libpgtcl is pretty seriously broken |
Дата | |
Msg-id | 199810111204.OAA02106@nikita.wizard.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] TCL_ARRAYS code in libpgtcl is pretty seriously broken (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 didn't realize it could be called more than once for the same tuple. We must allocate and free a new string for each value. I will write a patch. > 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. I submitted the two patches at the same time but one of them was put in the contribs. > 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? Given the situation I agree that TCL_ARRAYS should be disabled by default. > 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. I completely agree on the last thing. It is something I have been asking from a long time but apparently nobody cared bout it. -- Massimo Dal Zotto +----------------------------------------------------------------------+ | Massimo Dal Zotto email: dz@cs.unitn.it | | Via Marconi, 141 phone: ++39-461-534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: finger dz@tango.cs.unitn.it | +----------------------------------------------------------------------+
В списке pgsql-hackers по дате отправления: