Re: [PATCHES] libpq type system 0.9a
От | Bruce Momjian |
---|---|
Тема | Re: [PATCHES] libpq type system 0.9a |
Дата | |
Msg-id | 200804090006.m3906B619619@momjian.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] libpq type system 0.9a (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] libpq type system 0.9a
(Andrew Chernow <ac@esilo.com>)
Re: [PATCHES] libpq type system 0.9a ("Merlin Moncure" <mmoncure@gmail.com>) |
Список | pgsql-hackers |
Tom Lane wrote: > This is still 100% backwards. My idea of a libpq hook is something that > could be used by libpgtypes *and other things*. What you are proposing > is something where the entire API of the supposed add-on is hard-wired > into libpq. That's just bad design, especially when the adequacy of > the proposed API is itself in question. > > When I say I'd accept some hooks into libpq, I mean some hooks that > could be used by either libpgtypes or something that would like to do > something roughly similar but with a different API offered to clients. > The particular hook that you seem to mostly need is the ability to > allocate some private memory associated with a particular PGconn object, > and maybe also with individual PGresults, and then to be able to free > that at PQclear or PQfinish. Try designing it like that. Agreed. A minimal change to libpq has a much better chance of being accepted. Let me remind people that the community is not required to accept any patch --- it is accepted based on community feedback. If we accepted everything our API would be a mess and Postgres would be much harder to use. I think a wise thing would be for the patch submitters to give a _basic_ outline of what PQparam is trying to accomplish --- I mean like 10-20 lines with a code snippet, or code snippet with/withouth PQparam. Right now there are too many people trying to guess. Of course, this should have been done at the start. I found this posting from August, 2007 but it isn't short/clear enough: http://archives.postgresql.org/pgsql-hackers/2007-08/msg00630.php I feel this API is foreign enough from what people expect from a typical database interface library that it should be a separate library with its own documentation, whether the library is a separate directory in core or in pgfoundry. FYI, it might be interesting to extend it to cover what ecpg wants --- we have been looking for a way to get the database-dependent parts of ecpg out of the ecpg directory and this might be a solution, _even_ if it makes your library larger. Again, I don't think we have trouble with another library, assuming it does something that many people want to do and it is so tied to the backend that it needs to be in core. (However, Tom's mention that the OIDs don't change weakens the logic that is should be in core.) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: