Re: fixing PQsetvalue()
От | Merlin Moncure |
---|---|
Тема | Re: fixing PQsetvalue() |
Дата | |
Msg-id | CAHyXU0wB85hJvgXff3BtZg+MhQ_f23_6JtEL=g1Dr4oCS3PBRw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fixing PQsetvalue() (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Jul 20, 2011 at 10:28 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Jul 18, 2011 at 6:38 AM, Pavel Golub <pavel@microolap.com> wrote: >> Hello, Merlin. >> >> I hope it's OK that I've added Andrew's patch to CommitFest: >> https://commitfest.postgresql.org/action/patch_view?id=606 >> >> I did this becuase beta3 already released, but nut nothig is done on >> this bug. > > So I finally got around to taking a look at this patch, and I guess my > basic feeling is that I like it. The existing code is pretty weird > and inconsistent: the logic in PQsetvalue() basically does the same > thing as the logic in pqAddTuple(), but incompatibly and less > efficiently. Unifying them seems sensible, and the fix looks simple > enough to back-patch. > > With respect to Tom's concern about boxing ourselves in, I guess it's > hard for me to get worried about that. I've heard no one suggest > changing the internal representation libpq uses for result sets, and > even if we did, presumably the new format would also need to support > an "append a tuple" operation - or the very worst we could cause it to > support that without much difficulty. > > So, +1 from me. right -- thanks for that. For the record, I think a rework of the libpq internal representation would be likely to happen concurrently with a rework of the API -- for example to better support streaming data. PQsetvalue very well might prove to be a headache -- just too hard to say. libpq strikes me as a 50 year plus marriage might: fractious, full of mystery and regrets, but highly functional. merlin
В списке pgsql-hackers по дате отправления: