Andrew Dunstan wrote: > The first thing it needs is lots and lots of documentation. I think it > probably needs a Section in the libpq chapter all on its own, preferably > with some examples. I think that lack alone is enough to keep it from > being committed for now. > > Second, the hook names are compared case insensitively and by linear > search. I don't see any justification for using case insensitive names > for hooks in a C program, so I think that part should go. And if we > expect to keep anything other than trivial numbers of hooks we should > look at some sort of binary or hashed search. > > The thing that is a bit disturbing is that the whole style of this > scheme is very different from the fairly simple APIs that the rest of > libpq presents. It's going to make libpq look rather odd, I think. I > would have felt happier if the authors had been able to come up with a > simple scheme to add API calls to export whatever information they > needed, rather than using this callback scheme.
My personal opinion is still that I would like to see a more general usefulness for these functions before adding them to libpq. The complexity of the API just mirrors my gut feeling on this. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
