libpq object hooks -- needs copy result
От | Merlin Moncure |
---|---|
Тема | libpq object hooks -- needs copy result |
Дата | |
Msg-id | b42b73150804240704g312286c3pd509bf39a374c34a@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: libpq object hooks -- needs copy result
|
Список | pgsql-hackers |
We are trying to clean up the object hooks patch (on the libpq side) in time for the May commit fest. The last version we posted is here: http://www.nabble.com/libpq-object-hooks-patch-to16707707.html Everything for the most part works ok but there is a problem with the function 'PQmakeResult' which essentially takes a PGconn and a list of attributes. The PGconn here is extra baggage: we really need a 'src' result (we are creating a result from a result with customization). We do need to copy some information out of the PGresult. With an eye towards sideband utility, we are suggesting: PQcopyResult(PGresult *dest, const PGresult *src, int numAttributes, PGresAttDesc *attDescs, int options); One nice thing about that is the following functions are no longer required. We needed them to pull some of the private information out of the result...since the deep copy happens inside libpq they are no longer necessary. PQobjectHooks PQresultObjectHooks The 'options' argument allows customizing the behavior of the copy with some flags, for example to copy (or not), tuples, notice hooks, object hooks, etc, or to use the src PGresult attDescs or to take the supplied list. PQcopyResult appears to be the only way the hooks can really work. At the time it is called, the originating PGconn could be destroyed and provides no useful information to the newly created result. This will also affect the hooks slightly but the ability to 'copy' a result is key. With the change, the hook approach appears to work quite well with libpq types. If this is acceptable, we will have a new hook patch up shortly. merlin
В списке pgsql-hackers по дате отправления: