On Mon, May 19, 2008 at 8:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Chernow <[EMAIL PROTECTED]> writes:
>> Here is an updated patch for what was called object hooks. This is now
>> called libpq events. If someone has a better name or hates ours, let us
>> know.
>
> This is starting to g
On Mon, May 19, 2008 at 10:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Chernow <[EMAIL PROTECTED]> writes:
>> 4. add a setter for result instance data
>>- There should also be a PQsetInstanceData(PGconn*, ...)
>>- I see no need for a passThrough setter
>
> Check, though I assume we'
On Sun, May 18, 2008 at 5:22 PM, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> Can we get the rows in tree order, please? I.e. something like this:
Is ordering by tree order defined in the standard when no explicit
order is given? If not, it probably returns them in the order they
are pulled up
On Sat, May 17, 2008 at 8:28 AM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
> Here is an updated patch for what was called object hooks. This is now
> called libpq events. If someone has a better name or hates ours, let us
> know.
Let's decide where to go with this. We have no objections to pus
On Fri, May 16, 2008 at 4:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> Right. I actually overlooked the 'passthrough' in
>> PQregisterEventProc. It turns out that we are still not quite on the
>&g
On Fri, May 16, 2008 at 3:49 PM, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On Fri, May 16, 2008 at 2:34 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
>> Tom Lane wrote:
>>>
>>> typedef void (*PGeventProc) (PGeventId eventId, const void *eventInf
On Fri, May 16, 2008 at 2:34 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>>
>> typedef void (*PGeventProc) (PGeventId eventId, const void *eventInfo,
>> void *passthrough);
>>
>> int PQregisterEventProc(PGconn *conn, PGeventProc proc, void
>> *passthr
On Fri, May 16, 2008 at 11:21 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> All of this is getting quite a long way from what was in the commitfest
> queue. Do we still want to try to get this in this cycle, or should it be
> marked returned to author for more work?
That's your call...we can hav
On Fri, May 16, 2008 at 10:59 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>>> typedef void *(*PGobjectEventProc)(PGobjectEventId evtId, ...);
>>> int PQregisterObjectEventProc(PGconn*, PGobjectEventProc);
>&g
On Thu, May 15, 2008 at 8:38 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
> We need to add members to a conn and result, that's pretty much it. To do
> this, an api user can register callbacks to receive notifications about
> created/destroyed states of objects. PQhookData is just like PQerrorMe
On Wed, May 14, 2008 at 10:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm wondering why the hooks need names at all. AFAICS all that
> libpq needs to know about a hook is a callback function address
> and a void * passthrough pointer.
I'm trying to make this work as you suggest.
It's pretty cl
On Wed, May 14, 2008 at 3:47 PM, daveg <[EMAIL PROTECTED]> 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 a
On Wed, May 14, 2008 at 10:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm wondering why the hooks need names at all. AFAICS all that
> libpq needs to know about a hook is a callback function address
> and a void * passthrough pointer.
For reference...here is what libpqtypes has to do to bind vi
On Wed, May 14, 2008 at 10:52 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Merlin Moncure wrote:
>> Regarding the other comments:
>> *) API structure: Our major objective was to minimize exports to
>> libpq. I think both copyresult and setvalue have some possible
>
On Wed, May 14, 2008 at 10:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> No, they could revise their patch to be more stylistically in keeping
> with libpq. I haven't looked at the current version of the patch yet,
> but the early versions seemed quite overengineered to me, so your
> criticism didn
On Tue, May 13, 2008 at 11:52 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> 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.
There has been a lot of
On Wed, May 14, 2008 at 8:18 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Right, it was more the case insensitive part that bothered me.
Done. We in fact had realized this was a mistake anyways following
some profiling of the libpqtypes library. In some scenarios, this
function gets called a l
Attached is an updated version of 'libpq object hooks'. The primary
purpose for libpq object hooks is to support our libpqtypes system
(not attached), but could possibly some nice sideband features to
libpq. We are hoping to sneak this into the May commit fest.
regards,
merlin
Index: exports.tx
Here is a patch to add a few functions to libpq:
PQmakeResult: creates a new result with attributes but no rows
PQsetValue: set a field inside a result, creating a row if necessary
(but only one at a time)
PQresultAlloc (basically public wrapper to existing internal function).
also, the attribute
Here is an updated version of the 'libpq-side' changes required to
implement the libpqtypes proposal. This fixes the complaints Tom had,
particularly the process lock on the various functions that kept
private state linked up with the PGconn. We did this in a slightly
different way than Tom propo
On Fri, Apr 11, 2008 at 2:49 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Andrew Chernow wrote:
> > I noticed several months ago, and came across it again today, that
> > libpq's pthread-win32.c implementation is using CreateMutex rather
> > than CRITICAL_SECTION. CreateMutex is like a sema
On Fri, Apr 11, 2008 at 1:47 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
> Here are the changes to libpq. It adds the ability to register an Object
> Hook and create a home-grown result. Patch adds 4 functions.
>
> We changed the name of PQresultSetFieldValue to PQsetvalue, which better
> comp
On Fri, Apr 4, 2008 at 6:56 PM, Alvaro Herrera
<[EMAIL PROTECTED]> 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
On Tue, Mar 25, 2008 at 4:21 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Merlin Moncure escribió:
> > The latest version of libpq type system is available here:
> > http://www.esilo.com/projects/postgresql/libpq/typesys-0.9a.tar.gz
>
> This patch is not in diff -
On Wed, Mar 5, 2008 at 5:47 PM, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
> Merlin Moncure wrote:
> > 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 th
://www.esilo.com/projects/postgresql/libpq/typesys-0.9a.tar.gz
The following modifications where made:
*) documentation fixes
*) parameter resets are no longer automatic
*) updated to patch vs. REL8_3_STABLE
Merlin Moncure & Andrew Chernow
eSilo
--
Sent via pgsql-patches mailing list (pgsql-pat
Hackers,
Following is a patch to force the path type not to accept a path with
zero points. This appears to be illegal in the parser, but possible
when sending a well formed packed in binary with zero points. The old
behavior was this:
ERROR: floating-point exception
DETAIL: An invalid floati
On Dec 8, 2007 6:50 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Please note that I'm not saying that fixing that issue means the patch
> > is acceptable. Personally I'm not sure that this is a worthy goal you
> > are pursuing here. Wouldn't it be a goo
On Dec 6, 2007 11:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I want to buy into the idea that libpq should know explicitly about each
> and every backend datatype.
I don' t necessarily agree with this. First of all, the server gives
you an oid for the column which introduces the dependency...th
On Dec 5, 2007 2:44 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Andrew Chernow escribió:
>
> > Also changed PQputint8's prototype. Previously, it was using a void* as
> > the value argument, due to a lack of a portable 64-bit type in libpq. We
> > found an intersting way around this by using m
On 8/31/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On 8/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > > Here's a patch (minus catalog bump) which I think does that.
> >
> > Looks sane in a
On 8/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Here's a patch (minus catalog bump) which I think does that.
>
> Looks sane in a very quick once-over, but I didn't test it.
works fine (here was my test). thanks for quick resolution to this
issue. st
Attached is version 0.3 of the proposed PGparam extension to the libpq
API. I think we are wrapping up our changes in the short term and
will begin using our api for our internal projects. There were a lot
of changes and reorganizations, but the big features are that client
side geometry types we
On 8/17/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> Attached are some new functions that extend the libpq api to make
> calling the parameterized interfaces easier, especially when making
> binary calls. IMO, this fills one of the two big missing parts of the
> libpq api
I noticed that when psql accepts input from stdin or -f (but not -c),
and timing is set to on in .psqlrc, timing results are printed out to
stdout even when -q (quiet) is passed in.
This may not be the perfect solution, but it fixes the problem (I'm
having problems with bash scripts that are bork
t;
>
> The user doesn't need to check the status of the transaction if he just
> needs to end it. Just fire the END command and it'll take care of whether to
> COMMIT or ROLLBACK the transaction:
Hmm, right. Maybe I was thinking in savepoints, which Merlin Moncure is
so fond of
On 1/17/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
new v4
Changes
- removed -m command, design flaw in original spec, use -l instead
- added -k N command to cleanup archive and leave max N files
- fflush() points added to allow Windows debug
- bug fix: when .history file present
- bug fix: comma
On 1/17/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
On 1/17/07, Doug Knight <[EMAIL PROTECTED]> wrote:
> I confirm that I am seeing the exact same characteristic. Could you post
> your rotating script?
note: this is still a work in progress, the crude but effective sl
On 1/17/07, Doug Knight <[EMAIL PROTECTED]> wrote:
I confirm that I am seeing the exact same characteristic. Could you post
your rotating script?
note: this is still a work in progress, the crude but effective sleep
5 is due to be replaced with a lock/fifo and there catch_wal.sh needs
to be r
On 12/28/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Thu, 2006-12-28 at 19:26 +, Simon Riggs wrote:
> On Thu, 2006-12-14 at 12:04 +, Simon Riggs wrote:
> > pg_standby and test framework, in separate .tar files
>
> New version (v2), following further testing.
>
> Signal handling not incl
On 1/10/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
What about a Mingw or VC++ psql with a BCC libpq? Is it possible to
link something like that?
It would be nice to have the libpq at least able to pass the regression
tests.
you can use microsoft/mingw compiled DLL files but not library fi
[resending this to the list, was silently dropped this afternoon?]
-- Forwarded message --
From: Merlin Moncure <[EMAIL PROTECTED]>
Date: Sep 19, 2006 11:57 PM
Subject: docs for advisory locks
To: pgsql-patches@postgresql.org
ok, here is the promised docs for the advisory
ok, here is the promised docs for the advisory locks.
some quick notes here: this is my first non trivial patch (albeit only
documentation) and i am a complete docbook novice. i also dont have
the capability to build docbook at the moment. so consider this a
very rough draft. any comments are
On 9/7/06, Nimesh Satam <[EMAIL PROTECTED]> wrote:
We also noticed that the database slow downs heavily at a particular
time..Can you suggest any tools which will help in diagnosing the root cause
behiond the data load.
possible checkpoint? poorly formulated query? it could be any number
of t
> Tom Lane wrote:
>
> > I thought renaming them was a better idea, actually.
>
> Here is a patch for that. I will apply this to HEAD later today.
>
> --
I'm getting compiler error (win32) which I think is related to this
patch:
postmaster.c: In function `SubPostmasterMain':
postmaster.c:3189:
Tom Lane wrote:
> > If the connection gets accepted, I'd expect *something* in the
> > postmaster logs -- can you check?
>
> I suspect Merlin's complaint has to do with the fact that the *user*
> doesn't see any error message. The way you've coded this, setsockopt
> failure during startup is trea
> Here's a patch that adds four new GUCs:
>
> tcp_keepalives (defaults to on, controls SO_KEEPALIVE)
> tcp_keepalives_idle (controls TCP_KEEPIDLE)
> tcp_keepalives_interval (controls TCP_KEEPINTVL)
> tcp_keepalives_count (controls TCP_KEEPCNT)
I just tested this on my windows XP machine r
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > Looks like this in lrand48(void):
_rand48_seed[1] > 1);
> > _rand48_seed[1] >> 1);
^^
The problem is the shift operator :). Anyways I double checked the
results and it works as
Alvaro wrote:
> Please search this message in the archives:
right. heh. Well, moving on...
tgl wrote:
> Since subids and offnums are only 16 bits, we could pack all of these
> cases into 64 bits with a 16-bit type identifier to distinguish the
> cases. That would mean that LOCKTAG doesn't get an
Getting a win32 compiler error based on yesterday's update to pg_ctl.c.
It's a 1 liner (1081):
if (StartServiceCtrlDispatcher(st)) == 0)
to
if (StartServiceCtrlDispatcher(st) == 0)
or, as I prefer it :)
if (0 == StartServiceCtrlDispatcher(st))
Merlin
---(end of broadcas
> Attached patch solves the problem for me.Didn't see anything of the
> problem you described about hangs in my implementation. Probably
because
> mine exits at the first sign of a linebreak.
I confirmed the fix. 8.0.0 now starts up with net start (this is where
I first noticed the problem). Whe
Tom Lane wrote:
> It's the increase in variance between the Unix and Windows code paths
> that's really bothering me. We went into this project on the promise
> that there weren't going to be thousands of lines of #ifdef WIN32
stuff,
> and I'm not happy in the least with the way postmaster.c looks
Dave Page wrote:
> OK, looks like the error below is a Win32 thing. The patch attached
> #ifdef'd out the permissions check on the private key file as it won't
> work under Windows anyway (a similar check in postmaster.c has has
> already been ifdef'd out for the same reason).
>
> Incidently, the
53 matches
Mail list logo
