bruce wrote:
>
> Uh, we need a context diff for this.
Uh, never mind. The final version has a context diff.
---
>
> ---
>
> Simon Riggs 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.
---
Si
Uh, we need a context diff for this.
---
Simon Riggs wrote:
> On Fri, 2007-07-13 at 15:01 +0200, Reviewer wrote:
>
> > I just read your patch in order to understand a little bit what will
> > happen in the next release.
>
Because this has not been applied, this has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
> I wrote:
> > I just blew the dust off my old copy of Knuth vol 2
Uhm, this is a one-line *bug fix*.
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> This has been saved for the 8.4 release:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> ---
>
> Gregory Stark wrote:
>>
>
I've applied the latest version of the patch to HEAD. Thanks for the
patches, Nikhil and Trevor -- we can take a look at improving INCLUDING
CONSTRAINTS for 8.4.
On Mon, 2007-16-07 at 15:50 +0530, NikhilS wrote:
> I agree, since its a LIKE operation and not inheritance as such, how about
> "src_id
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.
---
Si
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.
---
Si
Gregory Stark wrote:
>
> Uhm, this is a one-line *bug fix*.
There wasn't agreement on how it should be fixed, it is a minor bug, and
as you said, we should be focusing on the significant outstanding
patches submitted before feature freeze.
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gregory Stark wrote:
>
> pgbench's random number generator was only generating the first and last value
> in the spe
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.
---
Si
Magnus, what is your reaction to this patch?
---
Hannes Eder wrote:
> Magnus Hagander wrote:
> >Hannes Eder wrote:
> >> Is it worth doing this the "Perl-way" and using File::Find? If so, I
> can
> >> work an a patch for
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Zdenek Kotala wrote:
>
> I attach patch which renames following binaries
>
> createdb createlang createuser dropdb
I reported an incorrect description for auto-analyze in our documentation.
http://archives.postgresql.org/pgsql-hackers/2007-06/msg0.php
Here is a documentation fix for it.
There are the same mistakes in 8.1 and 8.2, not only in HEAD.
It had been true in contrib/pg_autovacuum at 8.0, but we
ch
> I'm looking for ways to make the patch simpler and less invasive.
Any objections to changing the name of "RedirectDead"? A RedirectDead
ItemId is not really redirected, it's just a stub representing a dead
tuple (the space for that tuple has been reused but an index entry may
still point to t
On Mon, 2007-07-16 at 13:11 +0200, Stefan Kaltenbrunner wrote:
> I'm slowly working on submitting patches to reduce the amount of (bogus)
> compiler warnings generated by various buildfarm members.
>
> Warthog(the unixware box) generates some 1140 lines of:
>
> UX:cc: WARNING: debugging and opti
Latest version of synchronous_commit = on | off
Applies cleanly to CVS HEAD. Passes make check with/without
synchronous_commit on in postgresql.conf, while running
--enable-cassert.
I expect to review this tomorrow to make sure everything is correctly
changed before requesting final review/commit
I'm slowly working on submitting patches to reduce the amount of (bogus)
compiler warnings generated by various buildfarm members.
Warthog(the unixware box) generates some 1140 lines of:
UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled
UX:cc: WARNING: debugging and opt
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> On the other hand what happens if you have constraints not deferred, insert a
> record, then set constraints deferred and update it?
After having a coffee this is obviously not a problem since if you have
constraints not deferred then the constraint
Hi,
> You suppose "src_options" is much more readable than "inhreloptions"
> or "inh_idxoptions"? Your call :).
Yeah, I'm not necessarily sure that it is. "inhreloptions" made me think
of table inheritance, whereas LIKE in general is more of a "source" =>
"target" copying operation. But I'm not
On Mon, 2007-16-07 at 14:28 +0530, NikhilS wrote:
> Guess you want to use "src_options" here to be uniform with usages
> elsewhere that you have replaced.
Thanks, good catch.
> You suppose "src_options" is much more readable than "inhreloptions"
> or "inh_idxoptions"? Your call :).
Yeah, I'm not
Tom Lane wrote:
I don't think this is right. If the original tuple was inserted by a
subtransaction of our transaction, it will have been checked at
subtransaction subcommit, no?
No, it will be checked at main transaction commit; the immediate_only
flag is FALSE for afterTriggerMarkEvents()
Hi,
Attached is a revised patch that does that. Barring any objections, I'll
apply this to HEAD tomorrow.
A minor correction below in your patch:
--- src/include/commands/defrem.h 16 Jul 2007 05:19:43 -
*** extern void DefineIndex(RangeVar *heapRe
*** 26,31
--- 26,
On Fri, Jul 13, 2007 at 10:50:16AM +0200, Magnus Hagander wrote:
> On Fri, Jul 13, 2007 at 09:29:59AM +0100, Simon Riggs wrote:
> > On Thu, 2007-07-12 at 19:36 +, ISHIDA Akio wrote:
> > > The following bug has been logged online:
> > >
> > > Bug reference: 3439
> > > Operating system: W
On Tue, 2007-10-07 at 12:53 +0530, NikhilS wrote:
> Yes, in the CREATE..LIKE case, options will be NULL and in the normal
> CREATE..INDEX case inhreloptions will be NULL. Note that options is a
> List of DefElem entries, whereas inhreloptions is a char pointer.
Hmm, right -- ugly. I'll just stick
On Sun, 15 Jul 2007, Tom Lane wrote:
> "Affan Salman" <[EMAIL PROTECTED]> writes:
> > With some time to spare, I thought I'd submit a quick-fix patch to the
> > issue I reported here:
> > http://archives.postgresql.org/pgsql-hackers/2007-07/msg00339.php
>
> I don't think this is right. If t
26 matches
Mail list logo
