Skip site navigation (1) Skip section navigation (2)

Re: libpq object hooks

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: daveg <daveg(at)sonic(dot)net>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, "Andrew Chernow" <ac(at)esilo(dot)com>
Subject: Re: libpq object hooks
Date: 2008-05-14 20:30:35
Message-ID: b42b73150805141330t635df4fchf4f94891d095467a@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Wed, May 14, 2008 at 3:47 PM, daveg <daveg(at)sonic(dot)net> wrote:
> On Wed, May 14, 2008 at 10:52:43AM -0400, Bruce Momjian wrote:
>>
>> One idea would be to add the libpq hooks but not document them.  This
>> way, we can modify or remove the API as needed in the future.  As
>> libpqtypes matures and we are sure what the API should be, we can
>> document it as stable and permanent.
>
> Perhaps it is just me, but undocumented interface are evil. Simply document
> it with the changable bits labled as such.

Well, in defense of Bruce, there is some precedent for that.  Anything
that queries binary currently falls under that umbrella (mostly
undocumented and changeable).  For functions exported by libpq
though...it's probably better to nail things down as much as possible
up front.

This is a big advantage of the hooks strategy overall, it allows us to
mature the library except for the interaction with libpq (ISTM Bruce
was trying to give us a little leeway here as well, and we appreciate
that).

merlin

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2008-05-14 20:48:42
Subject: Re: bug in localized \df+ output
Previous:From: Marko KreenDate: 2008-05-14 20:29:22
Subject: [rfc,patch] PL/Proxy in core

pgsql-patches by date

Next:From: Bruce MomjianDate: 2008-05-14 20:57:12
Subject: Fix for psql pager computations
Previous:From: davegDate: 2008-05-14 19:47:27
Subject: Re: libpq object hooks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group