I accidentally forgot to copy pgsql-patches earlier...
On Fri, 19 Jan 2007, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
Also, some of the equivalence class support code is O(n^2).
Yeah, at least :-(. But I find it hard to conceive of real-world
queries that would generate more
Hi,
While ago (sep-2006) I sent a patch for the UUID datatype, Did anyone
have time to review it yet?
Here it is again :)
Regards,
Gevik
*** ./backend/utils/adt/Makefile.orig 2006-09-19 12:05:41.0 +0200
--- ./backend/utils/adt/Makefile 2006-09-19 12:06:47.0 +0200
Roman Kononov wrote:
On 12/27/2006 01:15 PM, Tom Lane wrote:
I'm not convinced that you're fixing things so much as doing your best
to destroy IEEE-compliant float arithmetic behavior.
I think what we should probably consider is removing CheckFloat4Val
and CheckFloat8Val altogether,
Alvaro Herrera wrote:
Alvaro Herrera wrote:
I tested it in a VPATH and a normal build, and regression test still
pass. This is mostly Magnus' code: I merely stripped out the parts
unrelated to this change, and reworked the code a little. So the
possible bugs are likely mine.
Woops,
Simon Riggs wrote:
psql -f copy_nowal_prep.sql postgres
psql -f copy_nowal_test.sql postgres
Do we want an additional test case along these lines?
Agreed doc changes for Performance Tips forthcoming.
I am still waiting for the documentation patch.
--
Bruce Momjian
Alvaro Herrera wrote:
Other than that, if I don't see objections, I'll commit it later today.
Applied.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of
A modified version of this was applied by Alvaro.
---
Magnus Hagander wrote:
Magnus Hagander wrote:
Hello!
Per some previous discussion that I can't really recall if it was on or
off list, here is a WIP patch to
Bruce Momjian wrote:
A modified version of this was applied by Alvaro.
But note that the patch I applied was only the part of this that was not
Windows-specific. The rest is still needed to be able to use VC++
builds as buildfarm members. I'm not in a position to build that
however, but it
On Fri, 2007-01-19 at 10:25 +0100, Gevik Babakhani wrote:
While ago (sep-2006) I sent a patch for the UUID datatype, Did anyone
have time to review it yet?
I confess I haven't followed the discussion around this patch, but is
there a compelling reason to include this in the backend proper,
Alvaro Herrera wrote:
Bruce Momjian wrote:
A modified version of this was applied by Alvaro.
But note that the patch I applied was only the part of this that was not
Windows-specific. The rest is still needed to be able to use VC++
builds as buildfarm members. I'm not in a position to
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Other than that, if I don't see objections, I'll commit it later today.
Applied.
And apparently I broke most of the buildfarm, sorry :-( Working on it.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
On Fri, 2007-01-19 at 11:36 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
psql -f copy_nowal_prep.sql postgres
psql -f copy_nowal_test.sql postgres
Do we want an additional test case along these lines?
Agreed doc changes for Performance Tips forthcoming.
I am still
I can't read a 7z file on my end. Please email me the file and I will
put it at a URL.
---
Gurjeet Singh wrote:
On 1/15/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Gurjeet Singh wrote:
1)
I confess I haven't followed the discussion around this patch, but is
there a compelling reason to include this in the backend proper, rather
than contrib/?
AFAIK, It is/was part of the TODO for the core.
---(end of broadcast)---
TIP 5: don't
On Sat, 2007-01-20 at 00:21 +0100, Gevik Babakhani wrote:
AFAIK, It is/was part of the TODO for the core.
Well, I don't have a strong opinion either way, but I think it should be
given some thought.
As far as the code, looks pretty good. A few minor comments:
* varchar_uuid() should be named
Neil Conway wrote:
On Sat, 2007-01-20 at 00:21 +0100, Gevik Babakhani wrote:
AFAIK, It is/was part of the TODO for the core.
Well, I don't have a strong opinion either way, but I think it should be
given some thought.
As far as the code, looks pretty good. A few minor comments:
*
On Fri, 2007-01-19 at 19:19 -0500, Bruce Momjian wrote:
I think having it in core makes the most sense.
Why is that?
One question that comes to mind is how the submitted patch compares in
functionality to the other implementations of the UUID concept for
PostgreSQL, such as OSSP uuid (which
Given the recent changes to the regression scripts, the large object
regression test patch I submitted quite a while ago, and is currently in
the patch hold queue, no longer cleanly applies. This patch is
functionally the same as the last one, but cleanly applies to current CVS
head.
Note that
Oops, that patch did not actually apply cleanly. Try this one instead,
it should. Please disregard the previous copy. Sorry.
On Fri, 19 Jan 2007, Jeremy Drake wrote:
Given the recent changes to the regression scripts, the large object
regression test patch I submitted quite a while ago, and
Atached is a patch to allow pretty printing of system objects
(constraints, indexes, rules, and views) when doing a pg_dump via a
--pretty-print flag along with a warning in the docs to be careful about
doing so :)
--
Greg Sabino Mullane [EMAIL PROTECTED] [EMAIL PROTECTED]
End Point Corporation
So, do we want this patch? Are we OK on WIN32 alignment issues?
---
ITAGAKI Takahiro wrote:
The attached is a patch to define O_DIRECT by ourselves on Windows,
and to map O_DIRECT to FILE_FLAG_NO_BUFFERING.
There will
Where are we on this patch?
---
Pavel Stehule wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
if I comprehended it well CURSOR_OPT_SCROLL is set only when SCROLL is
cheap
(not when is possible). It's true?
Bruce Momjian wrote:
I should have been clearer. I think having in the main server or
/contrib makes sense. Having data types external to our source tree
doesn't seem to work too well because of changes in our API from time
to time.
When has the API for data types ever changed?
--
Peter
Peter Eisentraut wrote:
Bruce Momjian wrote:
I should have been clearer. I think having in the main server or
/contrib makes sense. Having data types external to our source tree
doesn't seem to work too well because of changes in our API from time
to time.
When has the API for data
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
When has the API for data types ever changed?
The API doesn't change, but the way to do things inside the type
functions does changes sometimes.
We've always done our best not to break user-defined datatypes without
need. uuid
Per previous discussion, the main problem with a uuid type is the
new-uuid generator function, which tends to involve a bunch of
not-so-portable assumptions and code. If we accept a uuid type in
either core or contrib, all of a sudden those portability issues are
our problem. I'd rather
Joshua D. Drake wrote:
Per previous discussion, the main problem with a uuid type is the
new-uuid generator function, which tends to involve a bunch of
not-so-portable assumptions and code. If we accept a uuid type in
either core or contrib, all of a sudden those portability issues are
our
Has this been applied, and should it be?
---
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe we could forcibly activate the freeze mode on a template database?
Might not be
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Atached is a patch to allow pretty printing of system objects
(constraints, indexes, rules, and views) when doing a pg_dump via a
--pretty-print flag along with a warning in the docs to be careful about
doing so :)
Why exactly is that a good idea?
On 1/20/07, Bruce Momjian [EMAIL PROTECTED] wrote:
I can't read a 7z file on my end. Please email me the file and I will
put it at a URL.
---
Gurjeet Singh wrote:
Please find attached the patches ported to HEAD as of
30 matches
Mail list logo
