I updated the patch set of SE-PostgreSQL (revision 1268).
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1268.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1268.patch
[3/6]
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4
> Hi all,
>
> I have some data [...]
Thanks for gathering this data.
The first thing I notice is that the two versions of Q17 that you are
running are actually not the exact same query - there are hard-coded
constants that are different in each case, and that matters. The
substituted parameter d
On Mon, 1 Dec 2008, Mark Wong wrote:
So then I attempted to see if there might have been difference between
the executing time of each individual query with the above parameters.
The queries that don't seem to be effected are Q1, Q4, Q12, Q13, and
Q15. Q17 suggests that anything higher than
On Thu, Nov 13, 2008 at 11:53 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> A lot of people have suggested raising our default_statistics target,
>> and it has been rejected because there's some O(n^2) behavior in the
>> planner, and it makes ANALYZE sl
On Mon, Dec 1, 2008 at 11:08 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> postgres=# SELECT to_timestamp('29-12-2005 01:02:3', 'DD-MM-
> HH24:MI:SS'); -- doesn't work
...
> I think the end of string should be treated like a field separator, colon in
> this example, and we should accept b
Is it possible to reproduce on your system?
I got the following result at the latest CVS HEAD independently from
the feature of SE-PostgreSQL. I could not get the result a week ago,
but could not find where cause the regression.
-- (1) make a dummy file.
[EMAIL PROTECTED] base]$ dd if=/dev/zero o
On Thu, Nov 6, 2008 at 1:07 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-11-05 at 13:23 -0500, Jonah H. Harris wrote:
>> On Wed, Nov 5, 2008 at 12:35 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> >> The "Join Removal" item fails to point to a patch, also.
>> >
>> > I've removed that en
> I had a deeper look at this now. The patch looks clean and applies without
> any problems, regression tests passes. However, ATRewriteTables() has a
> problem when adding columns with domains and constraints. Consider this
> small test case:
>
> CREATE TABLE bar (id INTEGER);
> CREATE OR REPLACE
Heikki,
I think that the Assert in is_temp_rel(Oid) in tablecmds.c should be
replaced by if (on_commits == NULL) return false;
As the use case below shows, a regular table can be created and hold a
LOCKTAG_RELATION lock that will trigger the call to is_temp_rel in
is_preparable_locktag. The as
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> You're not making a lot of sense here, because INSERT always affects
> exactly the named table. It's UPDATE and DELETE where the behavior
> is debatable.
*blink* Ah, right you are, had a typo in my testing script. Excellent
news, I'm now off
> For better or worse, we also allow these more questionable inputs:
Wow. Those are all pretty atrocious.
Even so, it's not clear to me that there's a lot of merit to changing
the behavior. If to_timestamp() isn't rigorous enough, you can always
stick some additional error checking in front of
Can anyone please help in getting a solution...
I have two table, 1 contains all details of a person with person id as
primary key.
the other table has person id and parent id both referring to person table
person id.
My query is i have to get all the parents of a given person name.
Please help me
Robert Haas wrote:
On Mon, Dec 1, 2008 at 10:33 AM, Greg Stark <[EMAIL PROTECTED]> wrote:
How would you parse an input format of just 'SS' ? is there something
ambiguous about '3' ? I don't see anything "bad" about using %d to
output an integer number of seconds.
+1.
It seems to me that it's
On Mon, 1 Dec 2008, Tom Lane wrote:
Greg Smith <[EMAIL PROTECTED]> writes:
I'd ultimately like to use the Python version as a spec to produce a C
implementation, because that's the only path to get something like this
integrated into initdb itself.
It won't get integrated into initdb in any c
On Mon, 1 Dec 2008, Robert Haas wrote:
I just gave this a try and got:
$ ./pgtune
Traceback (most recent call last):
File "./pgtune", line 20, in
from ctypes.wintypes import *
File "/usr/lib/python2.5/ctypes/wintypes.py", line 21, in
class VARIANT_BOOL(_SimpleCData):
ValueError: _type
Greg Smith <[EMAIL PROTECTED]> writes:
> I'd ultimately like to use the Python version as a spec to produce a C
> implementation, because that's the only path to get something like this
> integrated into initdb itself.
It won't get integrated into initdb in any case: a standalone tool is
the cor
On Mon, 1 Dec 2008, Dave Page wrote:
It's going to be of little use to 99% of Windows users anyway as it's
written in Python. What was wrong with C?
It's 471 lines of Python code that leans heavily on that language's
Dictionary type to organize everything. Had I insisted on writing
directly
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Another q: given that we no longer need fnmatch(), should we remove it
> from port,
Yes. configure runs slow enough already without testing for functions
we don't need (especially if the test involves more than bare existence,
as in this case).
"Robert Haas" <[EMAIL PROTECTED]> writes:
> Another point here is that we have always accepted single digits in dates:
Yeah, but that's the general datetime input code, which has rather
different goals than to_timestamp().
After thinking about it I'm inclined to feel that SS and friends should
in
On 1 dec 2008, at 18.10, Tom Lane <[EMAIL PROTECTED]> wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
I could assign it to a variable, but won't the compiler just optimize
that away?
Wouldn't count on that, particularly not if you are modifying other
strings at the same time.
I'm not mod
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I could assign it to a variable, but won't the compiler just optimize
> that away?
Wouldn't count on that, particularly not if you are modifying other
strings at the same time.
regards, tom lane
--
Sent via pgsql-hackers mail
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> However, I strongly lean towards the behavior in this case being to only
> fire the parent statement-level trigger. I could support the other way as
> well: I'm not going to add any triggers to the children anyway, so as long
> as the parent fires
Another point here is that we have always accepted single digits in dates:
portal=> select '2008-11-1'::date;
date
2008-11-01
(1 row)
portal=> select '2008-1-11'::date;
date
2008-01-11
(1 row)
If we're going to handle dates and timestamps inconsistently, there
Greg Stark wrote:
How would you parse an input format of just 'SS' ? is there something
ambiguous about '3' ? I don't see anything "bad" about using %d to
output an integer number of seconds.
The docs say that SS corresponds to "second (00-59)", so clearly it
should expect a two digit ze
On Mon, Dec 1, 2008 at 10:33 AM, Greg Stark <[EMAIL PROTECTED]> wrote:
> How would you parse an input format of just 'SS' ? is there something
> ambiguous about '3' ? I don't see anything "bad" about using %d to
> output an integer number of seconds.
+1.
It seems to me that it's pretty silly to s
I could assign it to a variable, but won't the compiler just optimize
that away?
//Magnus
Robert Haas wrote:
> Looks good to me, except for a somewhat excessive number of calls to
> strlen() on the same input data.
>
> ...Robert
>
> On Mon, Dec 1, 2008 at 10:31 AM, Magnus Hagander <[EMAIL PROTE
Looks good to me, except for a somewhat excessive number of calls to
strlen() on the same input data.
...Robert
On Mon, Dec 1, 2008 at 10:31 AM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Magnus Hagander wrote:
>> I think I agree with the idea that we should match wildcards only at the
>> begin
How would you parse an input format of just 'SS' ? is there something
ambiguous about '3' ? I don't see anything "bad" about using %d to
output an integer number of seconds.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
2. I can't see any possible way that matching a single component could
create security holes that would be eliminated by matching multiple
components, but I'm more skeptical about the other direction. What
about the old DNS hack where you create a DNS record for
example.co
On Thu, 2008-11-27 at 21:04 +0900, Koichi Suzuki wrote:
> We ran the
> benchmark for on hour with chekpoint timeout 30min and completion_target 0.5.
> Then, collected all the archive log and run PITR.
> --+++---
> WAL conditions
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>>> My feeling is that it ought to fire such triggers on *each* target.
>> This would amount to statement level triggers firing multiple times per
>> statement wouldn't it?
> No, because they'd be different triggers. A trigger on a parent tab
Magnus Hagander wrote:
> I think I agree with the idea that we should match wildcards only at the
> beginning of the name *for now*, and then see what people actually
> request :-) I'm less sure about the single-pathname-component part, but
> the argument around backwards compatible is certainly a
Dave Page wrote:
On Mon, Dec 1, 2008 at 3:02 PM, David E. Wheeler <[EMAIL PROTECTED]> wrote:
it depends on how you look at it, I suppose. If you look at ":xy" as "x"
being the 10s position and "y" being the 1s position, it makes no sense.
Suffice it to say, I don't look at it that w
On Dec 1, 2008, at 4:09 PM, Dave Page wrote:
On Mon, Dec 1, 2008 at 3:02 PM, David E. Wheeler
<[EMAIL PROTECTED]> wrote:
it depends on how you look at it, I suppose. If you look at ":xy"
as "x"
being the 10s position and "y" being the 1s position, it makes no
sense.
Suffice it to say, I
On Dec 1, 2008, at 4:07 PM, Alvaro Herrera wrote:
David E. Wheeler wrote:
Oh, well yeah, it should be consistent. But I'm still not sure
that :3
should be allowed. OTOH, who does that, anyway?
Anyone who prints times as %d:%d:%d. You can find those in the wild.
I guess I should have exp
On Mon, Dec 1, 2008 at 3:02 PM, David E. Wheeler <[EMAIL PROTECTED]> wrote:
> it depends on how you look at it, I suppose. If you look at ":xy" as "x"
> being the 10s position and "y" being the 1s position, it makes no sense.
Suffice it to say, I don't look at it that way :-). I'd wager most
peop
David E. Wheeler wrote:
> Oh, well yeah, it should be consistent. But I'm still not sure that :3
> should be allowed. OTOH, who does that, anyway?
Anyone who prints times as %d:%d:%d. You can find those in the wild.
--
Alvaro Herrerahttp://www.CommandPrompt.co
Robert Haas wrote:
>>> 2. I can't see any possible way that matching a single component could
>>> create security holes that would be eliminated by matching multiple
>>> components, but I'm more skeptical about the other direction. What
>>> about the old DNS hack where you create a DNS record for
On Dec 1, 2008, at 3:55 PM, Dave Page wrote:
I'm generally in favor of being generous in the input one can
accept, but in
this case it seems ambiguous to me. Is that supposed to be :30 or :
03?
There's no way to tell.
How is it ambiguous? The leading zero is technically redundant. A
trailin
>> 2. I can't see any possible way that matching a single component could
>> create security holes that would be eliminated by matching multiple
>> components, but I'm more skeptical about the other direction. What
>> about the old DNS hack where you create a DNS record for
>> example.com.sample.c
On Dec 1, 2008, at 3:52 PM, Tom Lane wrote:
I'm generally in favor of being generous in the input one can accept,
but in this case it seems ambiguous to me. Is that supposed to be :30
or :03? There's no way to tell.
But notice that we are allowing a single digit for the hour and minute
fields.
On Mon, Dec 1, 2008 at 2:45 PM, David E. Wheeler <[EMAIL PROTECTED]> wrote:
> On Dec 1, 2008, at 1:08 PM, Heikki Linnakangas wrote:
>
>> postgres=# SELECT to_timestamp('29-12-2005 01:02:3', 'DD-MM-
>> HH24:MI:SS'); -- doesn't work
>> ERROR: source string too short for "SS" formatting field
>>
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Dec 1, 2008, at 1:08 PM, Heikki Linnakangas wrote:
>> I think the end of string should be treated like a field separator,
>> colon in this example, and we should accept both of the above.
>> Opinions?
> I'm generally in favor of being generou
Robert Haas wrote:
>> Perhaps the best method would actually be to match only "*." at the
>> beginning of the CN for now, and see if people complain? I would much
>> like someone who knows more about what would be reasonable to speak up
>> here, but it seems we don't have anybody here who knows...
On Dec 1, 2008, at 1:08 PM, Heikki Linnakangas wrote:
postgres=# SELECT to_timestamp('29-12-2005 01:02:3', 'DD-MM-
HH24:MI:SS'); -- doesn't work
ERROR: source string too short for "SS" formatting field
DETAIL: Field requires 2 characters, but only 1 remain.
HINT: If your source string i
I just gave this a try and got:
$ ./pgtune
Traceback (most recent call last):
File "./pgtune", line 20, in
from ctypes.wintypes import *
File "/usr/lib/python2.5/ctypes/wintypes.py", line 21, in
class VARIANT_BOOL(_SimpleCData):
ValueError: _type_ 'v' not supported
This is FC7, inst
I like strict in general, but this doesn't seem logical:
postgres=# SELECT to_timestamp('29-12-2005 01:2:03', 'DD-MM-
HH24:MI:SS'); -- works
to_timestamp
2005-12-29 01:02:03+02
(1 row)
postgres=# SELECT to_timestamp('29-12-2005 01:02:3', 'DD-MM-
HH24:MI
Could anyone with a MinGW system please run the ecpg regression suite including
tcp checks for the current CVS HEAD for me?
Just run "make checktcp" in src/interfaces/ecpg and afterwards send me the file
.../ecpg/test/results/connect-test1.stderr. There is a special expected file
for MinGW which i
Breaking down of patch into sections works very well for review. Should
allow us to get different reviewers on different parts of the code -
review wranglers please take note: Dave, Josh.
Can you confirm that all the docs on the Wiki page are up to date? There
are a few minor discrepancies that m
Dave Page wrote:
> On Mon, Dec 1, 2008 at 3:21 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
>> On Sun, 30 Nov 2008, Greg Smith wrote:
>>
>>> Memory detection works on recent (>=2.5) version of Python for Windows
>>> now.
>> I just realized that the provided configuration is really not optimal for
>> W
On Mon, Dec 1, 2008 at 3:21 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
> On Sun, 30 Nov 2008, Greg Smith wrote:
>
>> Memory detection works on recent (>=2.5) version of Python for Windows
>> now.
>
> I just realized that the provided configuration is really not optimal for
> Windows users because of
51 matches
Mail list logo
