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
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 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
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,
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()
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
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
"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
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
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
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
> 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
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
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
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
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
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
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.
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
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
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:
>>
>
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
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.
>
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
bruce wrote:
>
> Uh, we need a context diff for this.
Uh, never mind. The final version has a context diff.
---
>
> ---
>
> Simon Riggs wrote:
> >
26 matches
Mail list logo
