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 the known
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
Windows users
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 is
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
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-
I just gave this a try and got:
$ ./pgtune
Traceback (most recent call last):
File ./pgtune, line 20, in module
from ctypes.wintypes import *
File /usr/lib/python2.5/ctypes/wintypes.py, line 21, in module
class VARIANT_BOOL(_SimpleCData):
ValueError: _type_ 'v' not supported
This is
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 is
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...
I
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 generous in the
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
DETAIL:
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
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.com and
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
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
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 Herrera
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
people
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
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 don't
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 way :-).
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
-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 table
has
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
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.com and
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:
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
beginning
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 PROTECTED]
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 say
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 zero
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 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, I'll
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 mailing
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
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
insist
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).
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
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 correct
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 module
from ctypes.wintypes import *
File /usr/lib/python2.5/ctypes/wintypes.py, line 21, in module
class VARIANT_BOOL(_SimpleCData):
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
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
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
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
-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
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
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 VIEW
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 entry now. The patch
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
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 both
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 slower, but
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
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
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]
51 matches
Mail list logo
