On Sun, 2010-07-18 at 22:47 -0400, Robert Haas wrote:
> But it seems
> that it's far from clear what to do about it, and it's not the job of
> this patch to fix it anyway.
Agreed.
> Regarding the actual patch, it looks mostly good. Questions:
>
> 1. Why in rewriteSupport.c are we adding a call
Bruce Momjian wrote:
> > The attached patch does as suggested. I added the recovery code to the
> > create tablespace function so I didn't have to duplicate all the code
> > that computes the path names.
> >
> > Attached.
>
> Uh, another question. Looking at the createdb recovery, I see:
>
>
Joe Conway wrote:
> "make dcheck" is running now (although seems rather slow).
Yeah, most of those tests completely reset the environment for each
permutation. I thought about changing it to update back to the same
"visible" initial state each time, but it struck me that since this
would accu
On Sun, Jul 18, 2010 at 1:20 PM, Tom Lane wrote:
> Andres Freund writes:
>> On Sunday 18 July 2010 18:02:26 Simon Riggs wrote:
>>> Then I think the fix is to look at the xmin values on all of the tables
>>> used during planning and ensure that we only use constraint-based
>>> optimisations in a s
On 07/18/2010 07:02 PM, Joe Conway wrote:
> On 07/18/2010 11:41 AM, Kevin Grittner wrote:
>> To run the tests included in the main patch (if you have python,
>> twisted, etc., installed), after the make check, run make dcheck.
>
> Question about dcheck. After install of twisted, I get:
>
> 8<
On Sun, 18 Jul 2010, David Christensen wrote:
It's helpful when you attach said patch. This has been rebased to current HEAD.
One minor thing I noticed in the updated patch.
You moved the '{' after the if(host) in command.c to it's own line(good) but
you used spaces instead of tabstops th
On 07/18/2010 11:41 AM, Kevin Grittner wrote:
> To run the tests included in the main patch (if you have python,
> twisted, etc., installed), after the make check, run make dcheck.
Question about dcheck. After install of twisted, I get:
8<-
bash-4.1$ make dcheck
make -
Kevin,
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> I can't picture anything which could be done with views which would
> allow me to issue one statement and see everything of interest about
> a table (etc.). You know: tablespace, owner, permissions, columns,
> primary key, foreign key
Hi Kevin,
On Sunday 18 July 2010 21:24:25 Kevin Grittner wrote:
> Stefan Kaltenbrunner wrote:
> > On 07/18/2010 08:58 PM, Andres Freund wrote:
> >> I am quite a bit surprised about all this discussion. I have a
> >> very hard time we will find anything people agree about and can
> >> remember wel
On 07/18/2010 09:00 PM, Kevin Grittner wrote:
Dimitri Fontaine wrote:
So what we'd need first is a series of named queries, which I
think psql provides for.
Any solution which only works within psql isn't a solution for a
large part of the problem space people are trying to address. One
imp
On Sun, 2010-07-18 at 20:39 +0200, Dimitri Fontaine wrote:
> SHOW TABLE foo;
Yes
> SHOW TABLES WHERE tablename ~ 'foo';
>
> SHOW ANY TABLE
> GROUP BY tablename
> HAVING array_agg(attributes) @> array['date'::regtype,
> 'time'::regtype];
For me, realistically, No.
Simplifying SQL should b
Le 18 juil. 2010 à 21:21, Andres Freund a écrit :
> Providing an easy wrapper is something I could agree without much problems
> (as
> it doesnt touch me). But starting several new toplevel commands which do not
> give everything (i.e. the ability to selectively use columns) but still want
> to
Le 18 juil. 2010 à 20:58, Andres Freund a écrit :
> On Sunday 18 July 2010 20:39:07 Dimitri Fontaine wrote:
>> SHOW ANY TABLE
>> GROUP BY tablename
>> HAVING array_agg(attributes) @> array['date'::regtype, 'time'::regtype];
> Why is that in *any* way better than
>
> SELECT *
> FROM meta.tables
>
Le 18 juil. 2010 à 21:00, Kevin Grittner a écrit :
> Dimitri Fontaine wrote:
>
>> So what we'd need first is a series of named queries, which I
>> think psql provides for.
>
> Any solution which only works within psql isn't a solution for a
> large part of the problem space people are trying to
Stefan Kaltenbrunner wrote:
> On 07/18/2010 08:58 PM, Andres Freund wrote:
>> I am quite a bit surprised about all this discussion. I have a
>> very hard time we will find anything people agree about and can
>> remember well enough to be usefull for both manual and automatic
>> processing.
>>
>>
Hi,
On Sunday 18 July 2010 21:02:59 Rob Wultsch wrote:
> On Sun, Jul 18, 2010 at 11:58 AM, Andres Freund wrote:
> > On Sunday 18 July 2010 20:39:07 Dimitri Fontaine wrote:
> >> SHOW ANY TABLE
> >> GROUP BY tablename
> >> HAVING array_agg(attributes) @> array['date'::regtype,
> >> 'time'::regtyp
On 07/18/2010 08:58 PM, Andres Freund wrote:
On Sunday 18 July 2010 20:39:07 Dimitri Fontaine wrote:
SHOW ANY TABLE
GROUP BY tablename
HAVING array_agg(attributes) @> array['date'::regtype, 'time'::regtype];
Why is that in *any* way better than
SELECT *
FROM meta.tables
...
Oh. The second
On Sun, Jul 18, 2010 at 11:58 AM, Andres Freund wrote:
> On Sunday 18 July 2010 20:39:07 Dimitri Fontaine wrote:
>> SHOW ANY TABLE
>> GROUP BY tablename
>> HAVING array_agg(attributes) @> array['date'::regtype, 'time'::regtype];
> Why is that in *any* way better than
>
> SELECT *
> FROM meta.tab
Dimitri Fontaine wrote:
> So what we'd need first is a series of named queries, which I
> think psql provides for.
Any solution which only works within psql isn't a solution for a
large part of the problem space people are trying to address. One
important goal is that if someone spends a day
On Sunday 18 July 2010 20:39:07 Dimitri Fontaine wrote:
> SHOW ANY TABLE
> GROUP BY tablename
> HAVING array_agg(attributes) @> array['date'::regtype, 'time'::regtype];
Why is that in *any* way better than
SELECT *
FROM meta.tables
...
Oh. The second looks like something I know. Oh. My editor
On 07/18/2010 11:41 AM, Kevin Grittner wrote:
>
> I'm attaching a fresh patch, but I think the only differences are:
Thanks for the detailed info. I managed to make my way through much of
the background info in the papers and wiki yesterday, so I will start
reviewing shortly.
> If you spot an
On Sunday 18 July 2010 19:20:25 Tom Lane wrote:
> Andres Freund writes:
> > On Sunday 18 July 2010 18:02:26 Simon Riggs wrote:
> >> Then I think the fix is to look at the xmin values on all of the tables
> >> used during planning and ensure that we only use constraint-based
> >> optimisations in a
Hi,
Le 18 juil. 2010 à 05:41, Robert Haas a écrit :
> On Sat, Jul 17, 2010 at 11:14 PM, Bruce Momjian wrote:
>> I am concerned that implementing a command syntax to show complex output
>> like above effectively means re-implementing a subset of SQL, and that
>> subset will never be as flexible.
>
On Jul 18, 2010, at 12:33 PM, David Christensen wrote:
>
> On Jul 18, 2010, at 12:30 PM, Tom Lane wrote:
>
>> David Christensen writes:
>>> machack:machack:5432=# \c "foo""bar"
>>> You are now connected to database "foo"bar".
>>
>> What this is reflecting is that backslash commands have their
On Jul 18, 2010, at 12:30 PM, Tom Lane wrote:
> David Christensen writes:
>> machack:machack:5432=# \c "foo""bar"
>> You are now connected to database "foo"bar".
>
> What this is reflecting is that backslash commands have their own weird
> rules for processing double quotes. What I was concern
David Christensen writes:
> machack:machack:5432=# \c "foo""bar"
> You are now connected to database "foo"bar".
What this is reflecting is that backslash commands have their own weird
rules for processing double quotes. What I was concerned about was that
double quotes in SQL are normally used f
On Jul 18, 2010, at 12:17 PM, David Christensen wrote:
>
> On Jun 21, 2010, at 9:00 AM, Tom Lane wrote:
>
>> Robert Haas writes:
>>> On Sun, Jun 20, 2010 at 10:51 PM, Steve Singer
>>> wrote:
One comment I have on the output format is that values (ie the database
name) are enclosed
Kevin Grittner wrote:
Comment style seems to be defined here:
http://developer.postgresql.org/pgdocs/postgres/source-format.html
as being:
/*
* comment text begins here
* and continues here
*/
You have these formats in your patch:
/* comment text begins here
* and continues here
Andres Freund writes:
> On Sunday 18 July 2010 18:02:26 Simon Riggs wrote:
>> Then I think the fix is to look at the xmin values on all of the tables
>> used during planning and ensure that we only use constraint-based
>> optimisations in a serializable transaction when our top xmin is later
>> th
Florian Pflug wrote:
> On Jul17, 2010, at 18:25 , Kevin Grittner wrote:
>> * Does it follow the project coding guidelines?
>>
>> Comments are not all in standard style.
> Does that refer to the language used, or to the formatting?
Formatting. Comment style seems to be defined here:
http://
On Jun 21, 2010, at 9:00 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 20, 2010 at 10:51 PM, Steve Singer
>> wrote:
>>> One comment I have on the output format is that values (ie the database
>>> name) are enclosed in double quotes but the values being quoted can contain
>>> double
"David E. Wheeler" writes:
> On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
>> I think there are two ways we can do this, seeing that most appear to be
>> in favor of doing it in the first place: Either we just flip the
>> default, make a note in the release notes, and see what happens. Or
Bruce Momjian writes:
> I have applied the attached check, but without SO_PEERCRED I can't
> report the username which failed. Please adjust this if necessary.
AFAICT that should have been using the uid variable, not any of the
platform-specific things. Apparently this was not tested before com
On Sunday 18 July 2010 18:02:26 Simon Riggs wrote:
> On Sun, 2010-07-18 at 17:28 +0200, Andres Freund wrote:
> > Unfortunately the same issue exists with constraint exclusion - and we
> > can hardly disable that for serializable transactions...
>
> Then I think the fix is to look at the xmin value
On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
> I think there are two ways we can do this, seeing that most appear to be
> in favor of doing it in the first place: Either we just flip the
> default, make a note in the release notes, and see what happens. Or we
> spend some time now and ma
Bruce Momjian wrote:
> Tom Lane wrote:
> > Heikki Linnakangas writes:
> > > Maybe you should check that it points to the right location? Or drop and
> > > recreate the symlink, and ignore failure at mkdir.
> >
> > More specifically, ignore EEXIST failure when replaying mkdir. Anything
> > else
On Sun, 2010-07-18 at 17:28 +0200, Andres Freund wrote:
> Unfortunately the same issue exists with constraint exclusion - and we
> can hardly disable that for serializable transactions...
Then I think the fix is to look at the xmin values on all of the tables
used during planning and ensure that
Tom Lane wrote:
> Heikki Linnakangas writes:
> > Maybe you should check that it points to the right location? Or drop and
> > recreate the symlink, and ignore failure at mkdir.
>
> More specifically, ignore EEXIST failure when replaying mkdir. Anything
> else is still a problem.
Thanks for the
This commit caused my compile to fail on CVS HEAD:
revision 1.399
date: 2010/07/18 11:37:26; author: petere; state: Exp; lines: +88 -1
Add server authentication over Unix-domain sockets
This adds a libpq connection parameter requirepeer that specifies th
On Saturday 17 July 2010 09:55:37 Simon Riggs wrote:
> On Fri, 2010-07-16 at 23:03 +0200, Andres Freund wrote:
> > Sure its not that bad, but at least it needs to get documented imho.
> > Likely others should chime in here ;-)
>
> Don't understand you. This is a clear bug in join removal, test cas
I looked into the problem reported here:
http://archives.postgresql.org/pgsql-bugs/2010-07/msg00119.php
The reason it's failing is that when parse_agg.c calls
transformSortClause() to process the ORDER BY, the latter function
fails to match the "t" in ORDER BY to the one in the function's input
ar
Dean Rasheed writes:
> No. If x is 1e8 * y, then y will only affect the result in the 16th
> place. You can see this if you do a simple series expansion:
> sqrt(1+yx^2) = 1 + 1/2 yx^2 + O(yx^4)
Sigh, I went looking for that expansion yesterday and didn't find it.
Should've tried harder. I was r
Peter Eisentraut writes:
> I have never used the money type, so I'm not in a position to argue what
> might be typical use cases, but it is well understood that using
> floating-point arithmetic anywhere in calculations involving money is
> prohibited by law or business rules in most places. So w
Heikki Linnakangas writes:
> Maybe you should check that it points to the right location? Or drop and
> recreate the symlink, and ignore failure at mkdir.
More specifically, ignore EEXIST failure when replaying mkdir. Anything
else is still a problem.
regards, tom lane
On lör, 2010-07-17 at 10:00 -0500, Kevin Grittner wrote:
> True. If we added money * numeric, then it would make more sense to
> have money / money return numeric. On the other hand, I couldn't
> come up with enough use cases for that to feel that it justified the
> performance hit on money / mon
On lör, 2010-07-17 at 07:20 -0700, Andy Balholm wrote:
> On Jul 17, 2010, at 3:20 AM, Peter Eisentraut wrote:
>
> > On fre, 2010-07-16 at 10:31 -0400, Tom Lane wrote:
> >> The other argument that I found convincing was that if the
> >> operator was defined to yield numeric, people might think that
On lör, 2010-07-17 at 11:13 -0600, Alex Hunsaker wrote:
> its really no surprise that your test with 1600 columns had little
> effect. As it loops over the the indexes, then the index keys and
> then the group by items right? So I would expect the more indexes you
> had or group by items to slow i
On ons, 2010-07-14 at 10:48 -0400, Robert Haas wrote:
> On Fri, Jan 29, 2010 at 10:02 PM, Josh Berkus wrote:
> >> An actual plan here might look like "let's flip it before 9.1alpha1
> >> so we can get some alpha testing cycles on it" ...
> >
> > "Hey, let's flip it in 9.1 CF 1, so that we can have
On 17 July 2010 20:19, Tom Lane wrote:
> ... For instance, if x is 1e8 * y, then y*y
> fails to affect the sum at all (given typical float8 arithmetic), and
> you'll get back sqrt(x*x) even though y should have been able to affect
> the result at the 8th place or so. In the patch's calculation,
49 matches
Mail list logo
