On Sat, Jul 18, 2009 at 5:36 PM, Jaime
Casanova wrote:
> On Sat, Jul 18, 2009 at 3:38 PM, Robert Haas wrote:
>> On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine
>> 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
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 (pgsql-hackers@postg
On Sat, Jul 18, 2009 at 5:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine
>> 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
>>> th
On Sat, Jul 18, 2009 at 12:49 PM, Tom Lane 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 rearrangements but
Jaime Casanova writes:
> On Sat, Jul 18, 2009 at 6:25 PM, Merlin Moncure 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 the right direction, and sidesteps
>> so
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 semanti
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 s
On Sat, Jul 18, 2009 at 6:25 PM, Merlin Moncure wrote:
> On Sat, Jul 18, 2009 at 5:21 PM, Jaime
> Casanova 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).
On Sat, Jul 18, 2009 at 5:21 PM, Jaime
Casanova 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 nice step in the right directi
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
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 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 Da
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
immediately
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 d
On Sat, Jul 18, 2009 at 3:38 PM, Robert Haas wrote:
> On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine
> 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 fr
Robert Haas writes:
> On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine
> 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
On Tue, Jul 7, 2009 at 3:31 PM, Marko
Tiikkaja 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 don't work either.
>
my qu
"Kevin Grittner" 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 complex
databases, and it just
On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine 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 fest.
In general
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 n
On Sat, Jul 18, 2009 at 1:19 PM, Josh Berkus 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:
> http://it.toolbox.com/blogs/database-soup/thinking-about-row-leve
On Sat, Jul 18, 2009 at 8:25 PM, Robert Haas wrote:
> On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
> Takahiro 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
On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
Takahiro 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 via pgsql-hackers mailing list
On Sat, Jul 18, 2009 at 6:35 PM, Alan Li 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 AppenRelInfo dyn
On Tue, Jul 14, 2009 at 10:14 AM, Alvaro
Herrera 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 sure you specify the
On Fri, Jul 17, 2009 at 11:10 AM, Dimitri Fontaine 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 least for me,
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 2>&1
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
"Kevin Grittner" 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 used has USE_PGXS defined
On Sat, Jul 18, 2009 at 3:13 AM, Greg Stark wrote:
> This part:
>
> ! /* only try to optimize children rel's */
> ! foreach (lc, root->append_rel_list)
> ! {
> ! AppendRelInfo *a = (AppendRelInfo *) lfirst(lc);
> !
> !
Andrew Dunstan 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 doing make and sudo
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
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 oth
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:
> >
> > $(
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 (
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 (pgsql-hackers@postgre
Andres Freund 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 impossible ordering.
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 consens
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 q
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 to
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 "pu
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 o
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) that
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 tit
On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhout 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 accepted.
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. dy
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
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 --enable-cass
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 t
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 8.
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
2009/7/15 Tom Lane :
> 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 ugly:
bool
inde
2009/7/18 Bernd Helmle :
> --On Donnerstag, März 05, 2009 08:41:28 +0100 Pavel Stehule
> 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 hun
--On Donnerstag, März 05, 2009 08:41:28 +0100 Pavel Stehule
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 applied to current CVS.
53 matches
Mail list logo
