"Ugh, I started the wrong version of psql again".
This patch offers basic backwards compatibility, so a version 8.4 psql
can successfully do common operations on Postgres 8.0, 8.1, 8.2 and
8.3. I expect it's incomplete support, but as of yet I can't find an
actual problem. To me it is a step
Attached is the latest patch. It has addressed the requested changes found
here: http://archives.postgresql.org/pgsql-patches/2008-05/msg00389.php
Its a tarball because there are two new files, libpq-events.c and
libpq-events.h. The patch is in the tarball as well as attached to the email.
Tom Lane 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're not expecting PQsetInstanceData to
propagate to previously cr
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'
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're not expecting PQsetInstanceData to
propagate to previously created PGresult
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Now that upper/lower/initcase do not modify the passed string, I have
> simplified formatting.c with the attached patch.
I was thinking the same thing while reading the patch. But please,
make str_toupper() and friends declare their argument "const" if
Will make all of those changes. We appreciate the help.
1. remove global registration :(
2. New Name: PGCallback
3. use instanceData and passThrough names (passThrough with upper 'T')
3. separate getters for conn/result instanceData and passthrough
4. add a setter for result instance data
Now that upper/lower/initcase do not modify the passed string, I have
simplified formatting.c with the attached patch.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can
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 get there, though I am still desperately unhappy
with the notion of "global"
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> I'm not completely satisfied with the way this looks, so I'll try a
>> slightly different approach next: Instead of having one SMgrRelation per
>> fork, add an extra ForkNumber argument to all the smgr functions.
> H
Gregory Stark írta:
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
From an implementation point of view, the only difference between
breadth-first and depth-first is that your tuplestore needs to be LIFO
instead of FIFO.
I think it's not so simple. How do you reconcile that con
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have fixed all these items and the updated patch is at:
> ftp://momjian.us/pub/postgresql/mypatches/lc_time
Applied with further fixes --- mostly, ensure that it doesn't leave a
crash-inducing corrupted cache if strdup() returns NULL, and make th
Tom Lane a écrit :
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
Have at it then. Prove me wrong.
IMO the problem isn't the one off support for all supported version of
Pg... say 7.4 -> 8.4. The problem is of on going maintenance.
/me doesn't think it is worth the ef
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
> From an implementation point of view, the only difference between
> breadth-first and depth-first is that your tuplestore needs to be LIFO
> instead of FIFO.
I think it's not so simple. How do you reconcile that concept with the join
plans l
On Sun, 2008-05-18 at 22:17 -0700, David Fetter wrote:
> On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote:
> > "Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
> > > Also, it seems there are no infinite recursion detection:
> > >
> > > # with recursive x(level, parent, child) as (
> >
On Mon, May 19, 2008 at 05:57:17PM +0900, Yoshiyuki Asaba wrote:
> Hi,
>
> > I think it's the other way around. The server should not emit
> > infinite number of records.
>
> How about adding new GUC parameter "max_recursive_call"?
Couldn't we just have it pay attention to the existing
max_stack
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 11:56:17AM +0200, Zoltan Boszormenyi wrote:
>From an implementation point of view, the only difference between
breadth-first and depth-first is that your tuplestore needs to be LIFO
instead of FIFO.
Are you sure? I think a LIF
On Mon, May 19, 2008 at 11:56:17AM +0200, Zoltan Boszormenyi wrote:
> >From an implementation point of view, the only difference between
> >breadth-first and depth-first is that your tuplestore needs to be LIFO
> >instead of FIFO.
>
> Are you sure? I think a LIFO tuplestore would simply return rev
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 08:19:17AM +0200, Zoltan Boszormenyi wrote:
The standard has a clause to specify depth-first order. However doing a
depth-first traversal would necessitate quite a different looking plan and
it's far less obvious (to me anyways) how to do i
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 08:19:17AM +0200, Zoltan Boszormenyi wrote:
The standard has a clause to specify depth-first order. However doing a
depth-first traversal would necessitate quite a different looking plan and
it's far less obvious (to me anyways) how to do i
Yoshiyuki Asaba írta:
Hi,
From: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Mon, 19 May 2008 08:19:17 +0200
Also, it seems there are no infinite recursion detection:
# with recursive x(level, parent, child) as (
select 1::integer, * from
Hi,
From: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Mon, 19 May 2008 08:19:17 +0200
> >> Also, it seems there are no infinite recursion detection:
> >>
> >> # with recursive x(level, parent, child) as (
> >>select 1::integer, * from test_con
On Mon, May 19, 2008 at 08:19:17AM +0200, Zoltan Boszormenyi wrote:
> >The standard has a clause to specify depth-first order. However doing a
> >depth-first traversal would necessitate quite a different looking plan and
> >it's far less obvious (to me anyways) how to do it.
>
> That would be even
Gregory Stark írta:
This is indeed really cool. I'm sorry I haven't gotten to doing what I
promised in this area but I'm glad it's happening anyways.
"Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
Can we get the rows in tree order, please?
...
After all, I didn't specify any ORDER BY cl
24 matches
Mail list logo
