Re: [PATCHES] libpq type system 0.9a
От | Andrew Chernow |
---|---|
Тема | Re: [PATCHES] libpq type system 0.9a |
Дата | |
Msg-id | 47FBBACB.3020905@esilo.com обсуждение исходный текст |
Ответ на | Re: [PATCHES] libpq type system 0.9a ("Greg Sabino Mullane" <greg@turnstep.com>) |
Ответы |
Re: [PATCHES] libpq type system 0.9a
("Joshua D. Drake" <jd@commandprompt.com>)
Re: [PATCHES] libpq type system 0.9a (Martijn van Oosterhout <kleptog@svana.org>) Re: [PATCHES] libpq type system 0.9a ("Greg Sabino Mullane" <greg@turnstep.com>) |
Список | pgsql-hackers |
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@turnstep.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/
В списке pgsql-hackers по дате отправления: