libpq hooks patch v2
От | Merlin Moncure |
---|---|
Тема | libpq hooks patch v2 |
Дата | |
Msg-id | b42b73150804140803j5f0f554dx148bd8eabe38fc56@mail.gmail.com обсуждение исходный текст |
Список | pgsql-patches |
Here is an updated version of the 'libpq-side' changes required to implement the libpqtypes proposal. This fixes the complaints Tom had, particularly the process lock on the various functions that kept private state linked up with the PGconn. We did this in a slightly different way than Tom proposed...by keeping a void* in the PGobjectHooks struct. While we think this approach works, it is possibly to complicated for what it does. This could possibly be said of the hooking approach in general. We can't think of a good use case for other applications to use the hooks. The hook system feels awkward on both sides (in libpq, and libpqtypes). Why keep code abstract when it only has one real purpose? Possibly, a better approach than the hooking system is a wholesale wrapping of libpq, introducing a extended PGconn struct (PQTconn for example), with the private state stored in there and passed to all the libpqtypes functions. This would mean a complete new API, something we wanted to avoid. We see our proposal as a natural extension of libpq, library code, not application code. This difference of perception is perhaps what the impasse is. We think our other proposed strategy is better...namely to load the libpqtypes functionality with dlopen and keep 'stub' functions inside libpq which raise a runtime error if the library is not loaded. This resolves a major raised complaint, library size, and allows the stub functions to better handle certain things that should be in libpq, for example error handling. We understand this raises the bar for libpqtypes in terms of consensus...since it pushes certain aspects of libpqtypes into libpq, the whole thing has to be 'signed off' on, and there has naturally been a certain amount of resistance so far. At this point, function stubs (PQparamExec and friends) are all we are proposing to add to libpq. The remainder of the code can exist in core, pgfoundry, etc. This is much more direct and useful to libpq developers than a abstract hooking interface. merlin
Вложения
В списке pgsql-patches по дате отправления: