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,
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 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 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 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
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
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
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
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
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
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
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
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
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 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
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
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
"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
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
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://
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
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
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
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: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
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
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 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
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 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
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 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
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
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
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.
>>
>>
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
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: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
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
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
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
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
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 -
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 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, 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
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
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:
>
>
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
49 matches
Mail list logo
