Hi,
From: Neil Conway <[EMAIL PROTECTED]>
Subject: [PATCHES] [8.4] Updated WITH clause patch (non-recursive)
Date: Sat, 26 Jan 2008 23:58:40 -0800
> Attached is an updated version of Greg Stark's patch to add support for
> the non-recursive variant of the SQL99 WITH clause[1].
I found a bug with
We need more testing to show this is a good idea.
---
Manolo _ wrote:
>
> HI.
>
> I send you the diff of my code against the current CVS TIP.
> Please tell me if it's what you were asking for.
>
> Thanks.
>
> Regards, Ma
Gregory Stark írta:
"Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
Zoltan Boszormenyi írta:
Gregory Stark írta:
4) Your problems with tsearch and timestamp etc raise an interesting
problem.
We don't need to mark this in pg_control because it's a purely a run-time
issue
Zoltan Boszormenyi wrote:
> For genbki.sh, to correctly determine whether HAVE_LONG_INT_64
> is defined, the attached bugfix is needed in the configure.in machinery.
> This way the pg_config.h actually conforms to the comments for
> HAVE_LONG_INT_64 and HAVE_LONG_LONG_INT_64.
I think this part of
"Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
> Zoltan Boszormenyi írta:
>> Gregory Stark írta:
>>> 4) Your problems with tsearch and timestamp etc raise an interesting
>>> problem.
>>>We don't need to mark this in pg_control because it's a purely a run-time
>>>issue and doesn't affect
Zoltan Boszormenyi írta:
BTW I found the tsearch bug, it was a missing conversion of float4
in gistproc.c, it was an unfortunate detail that this didn't cause a
segfault,
it woul have been easier to find. Now there are no failing regression
tests.
Disregards this patch, the bugfix for tsearc
Zoltan Boszormenyi írta:
Gregory Stark írta:
4) Your problems with tsearch and timestamp etc raise an interesting
problem.
We don't need to mark this in pg_control because it's a purely a
run-time
issue and doesn't affect on-disk storage. However it does affect ABI
compatibility with
Gregory Stark írta:
Ok, ignore my previous message. I've read the patch now and that's not an
issue. The old code path is not commented out, it's #ifdef'd conditionally on
HAVE_LONG_INT_64 is right (well it seems right, it's a bit hard to tell in
patch form).
A few comments:
1) Please don't inc
Ok, ignore my previous message. I've read the patch now and that's not an
issue. The old code path is not commented out, it's #ifdef'd conditionally on
HAVE_LONG_INT_64 is right (well it seems right, it's a bit hard to tell in
patch form).
A few comments:
1) Please don't include configure in you
Hi,
Gregory Stark írta:
"Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
- the int8inc(), int2_sum() and int4_sum() used pointers directly from the
Datums
for performance, that code path is now commented out, the other code path
is correct for the AggState and !AggState runs and correct e
"Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
> - the int8inc(), int2_sum() and int4_sum() used pointers directly from the
> Datums
> for performance, that code path is now commented out, the other code path
> is correct for the AggState and !AggState runs and correct every time and now
> be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 24 Mar 2008 18:30:46 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Which part of "this is the wrong list" wasn't clear to you guys?
I actually didn't even notice. Sorry Tom.
Joshua D. Drake
- --
The PostgreSQL Company since 1997: http://www
Which part of "this is the wrong list" wasn't clear to you guys?
regards, tom lane
-
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Hi,
I got around to (almost) finalize the patch. What it does:
- fixes the configure define described in my previous mail
- when the value of HAVE_LONG_INT_64 == 1, the following types
are passed by value: int8, float8, time, timestamp, timestamptz
The time[stamp[tz]] types caused segfaults in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 24 Mar 2008 14:12:19 -0700
David Fetter <[EMAIL PROTECTED]> wrote:
> > Yeah, I have to had two reason for this patch. First is my personal,
> > because I don't like these names since 1999. And second is that
> > Solaris architects do not like
On Mon, Mar 24, 2008 at 09:19:42PM +0100, Zdenek Kotala wrote:
> Tom Lane napsal(a):
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> Where are we on this? Tom thinks we don't want this. TODO has:
>>> * Prefix command-line utilities like createuser with 'pg_'
>>> http://archives.postgre
Tom Lane napsal(a):
Bruce Momjian <[EMAIL PROTECTED]> writes:
Where are we on this? Tom thinks we don't want this. TODO has:
* Prefix command-line utilities like createuser with 'pg_'
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php
I think we need to make
Hello
http://archives.postgresql.org/pgsql-patches/2007-10/msg00161.php
I actualized this patch for current CVS
Regards
Pavel Stehule
*** ./doc/src/sgml/plpgsql.sgml.orig 2008-03-23 01:24:19.0 +0100
--- ./doc/src/sgml/plpgsql.sgml 2008-03-24 20:41:27.0 +0100
***
*** 1
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Where are we on this? Tom thinks we don't want this. TODO has:
> * Prefix command-line utilities like createuser with 'pg_'
> http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php
> I think we need to make a decision.
Well, I
Hello
This patch contains generate_subscripts functions, that generate
series of array's subscripts of some dimension:
postgres=#
create or replace function unnest2(anyarray)
returns setof anyelement as $$
select $1[i][j]
from generate_subscripts($1,1) g1(i),
generate_subscripts($1,2)
Where are we on this? Tom thinks we don't want this. TODO has:
* Prefix command-line utilities like createuser with 'pg_'
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php
I think we need to make a decision.
--
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I've had a chance to look at this now, and although it certainly does
> seem workable, there's a lot of duplication of code that I feel uneasy
> about. describeOneTableDetails essentially already duplicates the
> table buildling code in printQuery, so I
On 21/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > We can't just build the output table by hand like
> > describeOneTableDetails does? Admittedly it's kludgy, but it's not an
> > unprecedented kludge.
>
>
> Oh, I had forgotten the existence of tha
On 23/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Working through this patch now. I found one thing that seems to be
> a mistake (probably an overenthusiastic search&replace): the patch
> changes
> - {"iy", 2, dch_date, DCH_IY, TRUE},
> to
> + {"iyear", 2, DCH_IY, TRUE},
>
>
On 23/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Applied with some revisions to sync it with CVS HEAD --- primarily,
> since we now have a quote_literal(anyelement) function, it seemed
> important to add a quote_nullable(anyelement) variant. I also
> editorialized on the documentation ex
On Mar 23, 2008, at 9:25 PM, Volkan YAZICI wrote:
Hi,
On Sun, 23 Mar 2008, Martin Pihlak <[EMAIL PROTECTED]> writes:
Attached is a patch that enables tracking function calls through
the stats subsystem. Original discussion:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00377.php
Int
26 matches
Mail list logo
