Hello
This patch allows using any row expression in return statement and does
transformation from untyped row to composite types if it's necessary.
Regards
Pavel Stehule
_
Chcete sdilet sve obrazky a hudbu s prateli? http://messe
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> ... I'd do it myself but I'm heading to bed right now.
> ...
> I'll repost a reworked version at some point, if no one beats me to it.
I was planning to start looking at this patch tomorrow (unless Gavin
produces a new bitmap-index patch by then). I'll
Removed Cc: to pgsql-hackers.
Zoltán,
Zoltan Boszormenyi wrote:
> >Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches
> >
> >It will be applied as soon as one of the PostgreSQL committers reviews
> >and approves it.
Alvaro Herrera wrote:
> I just detected another problem with building ecpg in a VPATH
> environment. This patch fixes it for me.
I think you will find that $(top_builddir)/$(subdir) is equivalent
to "."
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(e
Hi,
I just detected another problem with building ecpg in a VPATH
environment. This patch fixes it for me.
This is needed because ecpg_config.h ends up in the build dir rather
than the source dir.
Thanks,
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The Postg
On Sat, Jul 29, 2006 at 09:14:16PM -0400, Greg Sabino Mullane wrote:
> Today on IRC David Fetter and some others were discussing version
> numbers and we realized that although libpq now provides the version of
> Postgres as a number, this is still a wheel that is being reinvented by
> apps many ti
Jonah H. Harris wrote:
> > Y'know I was gonna check up on that because my recollection was that it was
> > a 2/2 split as well, though I thought that was of people who made their
> > view clear rather than just -core (whose opinion in this case is no more
> > important than any of the other long
When trying to improve the rounding in interval_div and interval_mul,
I came across some behavior that seems counterintuitive to me:
test=# select '1.5 mon'::interval;
interval
-
1 mon 360:00:00
(1 row)
With the time/day/month interval struct introduced in 8.1, I'd expect
Joe Conway wrote:
I just received this (offlist), and have not had a chance to review it
myself yet, but figured I should post it now in case others want to have
a look and comment or discuss before feature freeze.
If there are no major objections to the concept, I'll take
responsibility to revi
Hi,
Quoting Bruce Momjian <[EMAIL PROTECTED]>:
> Great. Please supply documentation and it will be applied. Thanks.
Here it comes, including src+doc patches.
Updated sources according to Michael Fuhr's comments and fixed one FIXME.
Please check documentation patch thoroughly as I'm not nativ
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> How often does that case come up in the real world, for tables that are
>> large enough that you'd care about vacuum performance?
> I would have had the same objection if it resulted in substantially more
> complex
Tom Lane <[EMAIL PROTECTED]> writes:
> stark <[EMAIL PROTECTED]> writes:
>> There isn't really any need for the second pass in lazy vacuum if the table
>> has no indexes.
>
> How often does that case come up in the real world, for tables that are
> large enough that you'd care about vacuum perfor
stark <[EMAIL PROTECTED]> writes:
> There isn't really any need for the second pass in lazy vacuum if the table
> has no indexes.
How often does that case come up in the real world, for tables that are
large enough that you'd care about vacuum performance?
regards, tom lan
Jonah H. Harris wrote:
Y'know I was gonna check up on that because my recollection was that
it was a 2/2 split as well, though I thought that was of people who
made their view clear rather than just -core (whose opinion in this
case is no more important than any of the other long time
contri
There isn't really any need for the second pass in lazy vacuum if the table
has no indexes. The patch seems almost too easy but of course nothing having
to do with vacuum is as easy as it appears. Perhaps there are some gotchas I
haven't thought of?
Index: src/backend/commands/vacuumlazy.c
Y'know I was gonna check up on that because my recollection was that it was a
2/2 split as well, though I thought that was of people who made their view
clear rather than just -core (whose opinion in this case is no more important
than any of the other long time contributors imho). Don't suppos
On 8/27/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
1. Is not quite complete
Only because it wasn't merged into the core. Which, like I said,
would be difficult to get consensus on design, grammar, and
implementation when it's a brand new and non-standard feature only a
few people understan
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED] on behalf of Jonah H. Harris
Sent: Sun 8/27/2006 3:24 AM
To: Joshua D. Drake
Cc: Andrew Dunstan; Bruce Momjian; Tzahi Fadida; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Adding fulldisjunctions to the contrib
It's od
-Original Message-
From: [EMAIL PROTECTED] on behalf of Jonah H. Harris
Sent: Sun 8/27/2006 3:24 AM
To: Joshua D. Drake
Cc: Andrew Dunstan; Bruce Momjian; Tzahi Fadida; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Adding fulldisjunctions to the contrib
> It's odd, only 10 people
19 matches
Mail list logo
