Re: [PATCHES] libpq type system 0.9a

Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
>> I think you should conduct a wider survey before you make that decision.
>> In particular, I'd like to hear from driver writers like Greg Sabino
>> Mullane and Jeff Davis, as well as regular libpq users.
>
> I can state that there would be almost zero chance this would ever be
> used by DBD::Pg, as it would seem to add overhead with no additional
> functionality over what we already have. Unless I'm misreading what it
> does and someone can make the case why I should use it.
>
> - --
> Greg Sabino Mullane greg(at)turnstep(dot)com
> PGP Key: 0x14964AC8 200804081349
> http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
>
> -----BEGIN PGP SIGNATURE-----
>
> iEYEAREDAAYFAkf7sGkACgkQvJuQZxSWSsi8FgCgkGUGh2ieOAtvNlXX6orjO8oc
> 0bIAoPF7ojxM1c38kw7+L4Ar7FRZmdrn
> =U2BM
> -----END PGP SIGNATURE-----
>
>
>

This idea is for the libpq user, although driver writers could find it
handy as well. Really, anyone who uses libpq directly. That's the real
audience.

I don't know what overhead greg is referring to. How is DBD::pg
handling arrays of composites? Are you parsing text output? Wouldn't
it be less overhead to avoid text parsing and transmit binary data?

>>no additional functionality over what we already have
What about user-defined type registration, sub-classing user or built-in
type handlers, handling of all data types in binary. There is a lot
of new functionality added by this patch to the existing libpq.

I don't think the appropriate audience got a look at this, maybe posting
on general or libpq lists. From my perspective as a long time C coder,
this made my application code cleaner, easier to maintain and faster in
many cases. It removed a lot of code that is now handled by this patch.

I am not sure why Tom is worried about source code size, normally the
concern is linked size. Code comments were never finished, as the
library was changing so much to meet some requests. Instead, we focused
on providing API documentation and the overall idea (over 1000 lines).
This changed much less than the implementation.

I think the real issue is simply the wrong audience. Its the coder in
the field making heavy use of libpq that would find this appealing, not
really backend hackers.

It is disappointing because I was excited to here ideas from others,
which never happened.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/