On Mon, May 18, 2009 at 3:10 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
The attached is a patch to execute lo_unlink() before lo_create()
in pg_restore.
the patch applies almost cleanly (there are only minor and superfluos
hunks), compiles...
it works as expected...
this patch
--On Donnerstag, März 05, 2009 08:41:28 +0100 Pavel Stehule
pavel.steh...@gmail.com wrote:
Hello
I did some cleaning on this feature, and I hope so I solve some Tom's
objections
Attached is a cleaned up version of the patch, the one linked from the
commit fest has some hunks failing to be
2009/7/18 Bernd Helmle maili...@oopsware.de:
--On Donnerstag, März 05, 2009 08:41:28 +0100 Pavel Stehule
pavel.steh...@gmail.com wrote:
Hello
I did some cleaning on this feature, and I hope so I solve some Tom's
objections
Attached is a cleaned up version of the patch, the one linked from
2009/7/15 Tom Lane t...@sss.pgh.pa.us:
There is no reason at all to avoid an index AM API change if one is
useful.
Thinking about this a bit more, perhaps it would be better if I added
an out parameter to the AM for the uniqueness result, rather than
overloading the return value, which is quite
This part:
! /* only try to optimize children rel's */
! foreach (lc, root-append_rel_list)
! {
! AppendRelInfo *a = (AppendRelInfo *) lfirst(lc);
!
! if (a-child_relid == childrel-relid
Hi,
Le 17 juil. 09 à 23:24, Tom Lane a écrit :
It seems unlikely that the DB version number would be worth the prompt
space. In situations like that you'd much more likely need
identifying
info like the DB hostname and port number.
At work we have a fair number of database servers, some
On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote:
I'm starting to think that there's just no hope of this matching up
well enough with the way PostgreSQL already works to have a chance of
being accepted.
What I'm understanding here is the apparent requirement that the
Joshua Tolley wrote:
First, as you've already pointed out, this needs documentation.
/me looks at Stephen ;)
Once I added the missing semicolon mentioned earlier, it applies and builds
As we discussed outside of list, my compiler didn't picked that one
because I didn't use
On Fri, Jul 17, 2009 at 03:58:21PM +0200, Boszormenyi Zoltan wrote:
Attached is the short example I can reproduce with.
The version I used was final PostgreSQL 8.4.0, without our
extensions posted already. I added an indication to ecpg_type_name():
[z...@db00 ecpg-test]$ ecpg -C INFORMIX
On Wed, Jul 15, 2009 at 07:17:17PM +0200, Böszörményi Zoltán wrote:
as asked by Michael Meskes, I have split up our ECPG patchset:
Just a couple quick comments.
It appears to me (without much testing) that the patches still partly rely on
each other. But I cannot see a reason for this.
1.
On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhoutklep...@svana.org wrote:
On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote:
I'm starting to think that there's just no hope of this matching up
well enough with the way PostgreSQL already works to have a chance of
being
On Friday 17 July 2009 15:58:27 Richard Huxton wrote:
1. Fixed navigation
Copy STYLING/stylesheet.css over the existing one and you will have
static navigation links top and bottom of the page.
Looks good.
2. Titles on navigation links.
Run ./STYLING/title_links.pl and it should add title
Peter Eisentraut wrote:
This looks very cool, but should probably be implemented via a stylesheet
change instead of some Perl parsing some HTML. :-) I'm not sure if this
actually addresses Andrew's original concern, though.
No, it doesn't. David Wheeler's navigation (see upthread)
I spent a bit of time looking into why GEQO behaves so miserably on the
test case Andres Freund presented here:
http://archives.postgresql.org/message-id/200907091700.43411.and...@anarazel.de
The difficulty seems to be that the problem query is full of join order
restrictions; in particular lots
Alvaro Herrera wrote:
Bruce Momjian wrote:
Something is certainly wrong. Did we change sequence table format from
8.3 to 8.4?
8.3 does not have start_value.
Looking at an invalidly-migrated sequence's columns:
regression= \d serialtest_f2_foo
Sequence
Folks,
At this point, SE-PostgreSQL has taken up a *lot* of community
resources, not to mention an enormous and doubtless frustrating amount
of Kohei-san's time and effort, thus far without a single committed
patch, or even a consensus as to what it should (or could) do.
Rather than continuing
On Saturday 18 July 2009 17:48:14 Tom Lane wrote:
I spent a bit of time looking into why GEQO behaves so miserably on the
test case Andres Freund presented here:
http://archives.postgresql.org/message-id/200907091700.43411.and...@anaraze
l.de
The difficulty seems to be that the problem query
On Saturday 18 July 2009 18:06:00 David Fetter wrote:
Folks,
At this point, SE-PostgreSQL has taken up a *lot* of community
resources, not to mention an enormous and doubtless frustrating amount
of Kohei-san's time and effort, thus far without a single committed
patch, or even a consensus as
Andres Freund and...@anarazel.de writes:
This also explains why I saw nearly no improvement during the genetic search
itself. The paths out of random_init_pool were already hugely selected, so
there were not that many improvements to find and a change was relatively
like
to yield a
On Saturday 18 July 2009 12:31:34 Andres Freund wrote:
2. Apart from Kohei-san and Stephen Frost, is anybody actually
interested in having this feature at all?
I would definitely be interested.
+1
Best regards,
Jesper
--
Sent via pgsql-hackers mailing list
Andrew Dunstan wrote:
Peter Eisentraut wrote:
This looks very cool, but should probably be implemented via a
stylesheet change instead of some Perl parsing some HTML. :-) I'm not
sure if this actually addresses Andrew's original concern, though.
No, it doesn't. David Wheeler's navigation
Peter Eisentraut wrote:
On Wednesday 08 July 2009 02:09:20 Alvaro Herrera wrote:
It seems our makefiles fail to install fmgroids.h by make install in a
VPATH build.
I think the solution is to treat fmgroids.h just like pg_config_os.h,
i.e. add a line like this:
$(INSTALL_DATA)
David,
2. Apart from Kohei-san and Stephen Frost, is anybody actually
interested in having this feature at all?
I'm interested in a version of the feature. That is, I'm specifically
interested in an SEPostgres which delivers:
a) SELinux-label control (pluggable with TrustedSolaris and
On Sat, Jul 18, 2009 at 10:19:16AM -0700, Josh Berkus wrote:
David,
2. Apart from Kohei-san and Stephen Frost, is anybody actually
interested in having this feature at all?
I'm interested in a version of the feature.
Not, so far, one congruent to anything Kohei-san has actually sent,
Andrew Dunstan and...@dunslane.net wrote:
That's why I asked to see the make log. Maybe some environment
setting affected things?
Bingo! A few weeks back I had been experimenting with using the PGXS
compiles for our extensions, rather than expanding our tarballs in the
build tree and just
On Sat, Jul 18, 2009 at 3:13 AM, Greg Stark gsst...@mit.edu wrote:
This part:
! /* only try to optimize children rel's */
! foreach (lc, root-append_rel_list)
! {
! AppendRelInfo *a = (AppendRelInfo *) lfirst(lc);
!
!
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Bingo! A few weeks back I had been experimenting with using the PGXS
compiles for our extensions, rather than expanding our tarballs in the
build tree and just doing make and sudo make install there. On the
failing machine, the session I
On Sat, July 18, 2009 1:35 pm, Kevin Grittner wrote:
Out of curiosity, where is the make log to which you refer?
Just the output from make.
e.g. make make.log 21
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Fri, Jul 17, 2009 at 11:10 AM, Dimitri Fontainedfonta...@hi- I
couldn't apply it to current head because of bitrot. It applies fine
to
git commit bcaef8b5a0e2d5c143dabd8516090a09e39b27b8 [1] but
This is one of the things that I hate about the requirement to post
context diffs: filterdiff, at
On Tue, Jul 14, 2009 at 10:14 AM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Thank you very much for the patch. Well done for getting to this stage.
There is definitely much support for your work.
Thanks for the thorough review. Please when you add a comment to the
commitfest app, make
On Sat, Jul 18, 2009 at 6:35 PM, Alan Lia...@truviso.com wrote:
Yeah, are you running into the same issue as well? I tried to figure out a
way around the O(n^2) behavior, but there were no existing direct
relationship between the child subpath and its associated AppendRelInfo. I
think an
On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated version of multi-threaded pgbench patch.
Greg (Smith), do you have time to review this version? If not, I will
assign a round-robin reviewer when one becomes available.
...Robert
--
Sent
On Sat, Jul 18, 2009 at 8:25 PM, Robert Haasrobertmh...@gmail.com wrote:
On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated version of multi-threaded pgbench patch.
Greg (Smith), do you have time to review this version? If not, I will
On Sat, Jul 18, 2009 at 1:19 PM, Josh Berkusj...@agliodbs.com wrote:
b) Efficient constraint-based row-level security (as opposed to individual
row labelling)[1]
[...]
[1] For an explanation of the two ways to do row-level security, see here:
Hi,
Le 14 juil. 09 à 11:47, Itagaki Takahiro a écrit :
I updated Sampling profiler patch to be applied to HEAD cleanly.
Which I confirm, as I just spent some time to reviewing the patch (it
was left unassigned in the commit fest). Reviewing code didn't strike
anything so obvious that I'd
On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontainedfonta...@hi-media.com wrote:
So I'm going to change patch state to Returned with Feedback as I guess
we'll need to talk about the issue and find a way to solve it, and I don't
think this state prevent from getting back to the patch in this same
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Performance tests to follow in a day or two.
I'm looking to beg another week or so on this to run more tests. What
I can have by the end of today is pretty limited, mostly because I
decided it made the most sense to test this with big
On Tue, Jul 7, 2009 at 3:31 PM, Marko
Tiikkajamarko.tiikk...@cs.helsinki.fi wrote:
Hello.
Here's a patch(WIP) that implements INSERT .. RETURNING inside a CTE. Should
apply cleanly against CVS head.
The INSERT query isn't rewritten so rules and default values don't work.
Recursive CTEs
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontainedfonta...@hi-media.com
wrote:
So I'm going to change patch state to Returned with Feedback as I guess
we'll need to talk about the issue and find a way to solve it, and I don't
think this state prevent
On Sat, Jul 18, 2009 at 3:38 PM, Robert Haasrobertmh...@gmail.com wrote:
On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontainedfonta...@hi-media.com
wrote:
So I'm going to change patch state to Returned with Feedback as I guess
we'll need to talk about the issue and find a way to solve it, and I
Review feedback:
1. Compiler warning:
index.c: In function ‘index_create’:
index.c:784: warning: implicit declaration of function ‘SystemFuncName’
2. I know that the GIN, GiST, and Hash AMs don't use the
uniqueness_check argument at all -- in fact it is #ifdef'ed out.
However, for the sake of
Le 18 juil. 09 à 20:55, Robert Haas a écrit :
that indicate the base rev of the patch. In fact that rev is BEFORE
the one I based the patch on, which was
64b2da3f7778bc6fd3d213ceb9e73ff3b6e03890, and it actually applies OK
up until 0e3abe7ec78a3d51032d684598f188b0b0304fe9, the commit
On Sat, 2009-07-18 at 11:09 +0100, Dean Rasheed wrote:
Thinking about this a bit more, perhaps it would be better if I added
an out parameter to the AM for the uniqueness result, rather than
overloading the return value, which is quite ugly:
Sounds reasonable to me.
Regards,
Jeff
David Fetter asked:
1. Among the committers who could maintain the features, whatever
they turn out to be, who is actually volunteering to do so?
I am not a committer, but I saw a message about issues with documentation --
I would be willing to help on making documentation and comments
On Jul 18, 2009, at 9:54 AM, Richard Huxton wrote:
No, it doesn't. David Wheeler's navigation (see upthread) that he
uses for the Bricolage docs does, however.
Ah, if you can change the overall layout then the world is your
shellfish of choice. Would it be possible to include jquery? It's
On Sat, Jul 18, 2009 at 5:21 PM, Jaime
Casanovajcasa...@systemguards.com.ec wrote:
my questions first:
- what's the use case for this?
Being able to use 'returning' in a subquery is probably the #1 most
requested feature for postgresql (it's also a todo). Solving it for
'with' queries is a
Hi Robert, Hi all,
On Friday 12 June 2009 06:32:11 Robert Haas wrote:
OK, here it is again. Changes are the same as the previous version,
but this one should apply cleanly after today's pgindent run.
Not much to say here.
Patch applies cleanly, the changes look sensible and as far as I can
Hi Robert, Hi All,
Patch applies with some offset changes, code changes look sensible, I
personally like the new syntax and the features it may allow in future. One,
possibly big, gripe remains though:
The formerly valid statement which cannot be written without the parentheses
and stay
On Sat, Jul 18, 2009 at 6:25 PM, Merlin Moncuremmonc...@gmail.com wrote:
On Sat, Jul 18, 2009 at 5:21 PM, Jaime
Casanovajcasa...@systemguards.com.ec wrote:
my questions first:
- what's the use case for this?
Being able to use 'returning' in a subquery is probably the #1 most
requested
Jaime Casanova jcasa...@systemguards.com.ec writes:
On Sat, Jul 18, 2009 at 6:25 PM, Merlin Moncuremmonc...@gmail.com wrote:
Being able to use 'returning' in a subquery is probably the #1 most
requested feature for postgresql (it's also a todo). Solving it for
'with' queries is a nice step in
On Sat, Jul 18, 2009 at 12:49 PM, Tom Lanet...@sss.pgh.pa.us wrote:
We could refrain from collapsing the sub-problem during joinlist
formation. But the trouble with that is it creates a hard join order
restriction. Most of the restrictions are soft to some extent, ie,
you can do some
On Sat, Jul 18, 2009 at 5:28 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontainedfonta...@hi-media.com
wrote:
So I'm going to change patch state to Returned with Feedback as I guess
we'll need to talk about the
Greg (Smith), do you have time to review this version? If not, I will
assign a round-robin reviewer when one becomes available.
I can do a concurrency test of this next week.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list
On Sat, Jul 18, 2009 at 5:36 PM, Jaime
Casanovajcasa...@systemguards.com.ec wrote:
On Sat, Jul 18, 2009 at 3:38 PM, Robert Haasrobertmh...@gmail.com wrote:
On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontainedfonta...@hi-media.com
wrote:
So I'm going to change patch state to Returned with
54 matches
Mail list logo
