Re: [PATCHES] libpq type system 0.9a

I know there has been lots of versions and technical feedback related to
this proposed feature. However, I have talked to Tom and neither of us
see sufficient user request for this capability to add this code into
the core server. I recommend you place it on pgfoundry and see if you
can get a sufficient user-base there. If you need something exposed by
libpq that is not there already, please let us know.

One interesting idea would be if ecpg could use this functionality in
place of its own type-specific functions --- if that were the case, we
could reconsider adding this to core because it would be required by
ecpg.

Sorry for the bad news. I think we all hoped that enough interest would
be generated for this to be accepted.

---------------------------------------------------------------------------

Andrew Chernow wrote:
> Andrew Chernow wrote:
> > Joe Conway wrote:
> >> Alvaro Herrera wrote:
> >>> Merlin Moncure escribi?:
> >>>> Yesterday, we notified -hackers of the latest version of the libpq
> >>>> type system. Just to be sure the right people are getting notified,
> >>>> we are posting the latest patch here as well. Would love to get some
> >>>> feedback on this.
> >>>
> >>> I had a look at this patch some days ago, and the first question in my
> >>> mind was: why is it explicitely on libpq? Why not have it as a separate
> >>> library (say libpqtypes)? That way, applications not using it would not
> >>> need to link to it. Applications interested in using it would just need
> >>> to add another -l switch to their link line.
> >>>
> >>
> >> +1
> >>
> >> Joe
> >>
> >>
> >
> > What is gained by having a separate library? Our changes don't bloat
> > the library size so I'm curious what the benefits are to not linking
> > with it? If someone doesn't want to use, they don't have to. Similar
> > to the backend, there is stuff in there I personally don't use (like geo
> > types), but I'm not sure that justifies a link option -lgeotypes.
> >
> > The changes we made are closely tied to libpq's functionality. Adding
> > PQputf to simplify the parameterized API, adding PQgetf to compliment
> > PQgetvalue and added the ability to register user-defined type handlers
> > (used by putf and getf). PQgetf makes extensive use of PGresult's
> > internal API, especially for arrays and composites. Breaking this into
> > a separate library would require an external library to access the
> > private internals of libpq.
> >
> > Personally, I am not really in favor of this idea because it breaks
> > apart code that is very related. Although, it is doable.
> >
>
> I poked around to see how this would work. There are some problems.
>
> 1. members were added to PGconn so connection-based type handler information can
> be copied to PGparam and PGresult objects.
>
> 2. members were added to PGresult, referenced in #1. To properly getf values,
> the connection-based type handler information must be available to PGresult.
> Otherwise, PQgetf would require an additional argument, a PGconn, which may have
> been closed already.
>
> 3. PQfinish calls pqClearTypeHandler to free type info assigned to the PGconn.
>
> 4. PQclear also calls pqClearTypeHandlers
>
> It would also remove some of the simplicity. Creating a connection would no
> longer initialized type info, which gets copied to PGparam and PGresult. Type
> info includes a list of built-in handlers and backend config, like
> integer_datetimes, server-version, etc... That means an additional function
> must be called after PQconnectdb. But where would the type info be stored? It
> wouldn't exist in PGconn anymore? Also, this would require double frees. You
> have to free the result as well as the type info since they are no longer one
> object. Same holds true for a pgconn.
>
> There is something elegant about not requiring additional API calls to perform a
> putf or getf. It'll just work if you want to use it. You can use PQgetf on a
> result returned by PQexec and you can use PQputf, PQparamExec followed by
> PQgetvalue.
>
> --
> Andrew Chernow
> eSilo, LLC
> every bit counts
> http://www.esilo.com/
>
> --
> Sent via pgsql-patches mailing list (pgsql-patches(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-patches

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +