On 02.10.2010 00:20, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
Then instead of having a trigger file, the admin could just update the
status file in recovery.conf and save it (or overwrite the file).
This doesn't seem like a terribly bright idea. We've expended megabytes
of list
2010/10/3 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
2010/10/2 Jeff Davis pg...@j-davis.com:
On Fri, 2010-10-01 at 18:52 +0900, Hitoshi Harada wrote:
While tackling the top-level CTEs patch, I found that INSERT ...
VALUES isn't aware of ORDER BY / LIMIT.
From
Whoops...seems there was some minor mangling when I applied the
original patch by:
pe...@linux-peter-home:~/postgresql patch --version
GNU patch 2.6.1.81-5b68
snip***
pe...@linux-peter-home:~/postgresql patch -c contrib_isn-1.patch
I've attached a revised version, which I've carefully
2010/10/2 Pavel Stehule pavel.steh...@gmail.com:
Hello
updated version
* memsort removed
* window aggregate support blocked
I ran this patch and it looks good for committer.
Just one thing, in src/backend/utils/adt/Makefile median.o to compile
the new file is missing.
And I'm now thinking
Hi,
I try to install pgAdmin III using Yum on CentOS 5.5 (x86_64), but it
seems pgadmin3_90 package architecture is i386 in Yum repository.
# cat /etc/redhat-release
CentOS release 5.5 (Final)
# yum list pgadmin3_90
(snip)
Available Packages
pgadmin3_90.i386 1.12.0-1.rhel5
Hitoshi Harada umi.tan...@gmail.com writes:
DEFAULT is disallowed now in such VALUES list, but we can explain it
is allowed in a simple VALUES of INSERT case.
I don't think we really need to explain anything. This is per spec;
if you trace the way that a DEFAULT expression can appear in
I wrote:
After some back-and-forth among core and -packagers, we've agreed that
we're overdue for update releases for the back branches. Accordingly,
we'll be wrapping update tarballs of all active branches on Thursday
for public announcement Monday Oct 4.
We had a bit of difficulty with
On Sun, Oct 3, 2010 at 7:06 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
And I'm now thinking about how to make median happen in window
aggregate.
If you were to do this by extending tuplesort what extra features
would tuplesort need?
Would tuplesort need the ability to insert additional
.
=# CREATE RULE barrule AS ON UPDATE TO bar DO INSTEAD
-# WITH RECURSIVE t AS (SELECT -1)
-# INSERT INTO bar
-# WITH t AS (SELECT 1)
-# VALUES((SELECT * FROM t));
Regards,
--
Hitoshi Harada
toplevel-dml-cte.20101003.diff
Description: Binary data
--
Sent via pgsql-rrreviewers mailing
Our documentation in
http://www.postgresql.org/docs/9.0/interactive/hot-standby.html currently
says the following:
snip
Running DROP DATABASE, ALTER DATABASE ... SET TABLESPACE, or ALTER DATABASE
... RENAME on the primary will generate a WAL entry that will cause all
users connected to that
Hello
2010/10/3 Hitoshi Harada umi.tan...@gmail.com:
2010/10/2 Pavel Stehule pavel.steh...@gmail.com:
Hello
updated version
* memsort removed
* window aggregate support blocked
I ran this patch and it looks good for committer.
Just one thing, in src/backend/utils/adt/Makefile median.o
Hi,
I'm using pgadmin to administrate my postgreSQL database.
But now I was told to import a text file containing a table with fields
seperated by ';'
How Do I do that?
Regards
This is the sort of question that is far better suited to the
pgsql-gene...@postgresql.org mailing list or the
pgadmin-supp...@postgresql.org mailing list, but the answer is that
you should use the copy sql command:
http://www.postgresql.org/docs/current/static/sql-copy.html
--
Regards,
Peter
[ sorry for not responding on this sooner, it's been hectic the last
couple weeks ]
Sushant Sinha sushant...@gmail.com writes:
I looked at this patch a bit. I'm fairly unhappy that it seems to be
inventing a brand new mechanism to do something the ts parser can
already do. Why didn't you
On 2010-10-03 5:08 AM +0300, Steve Singer wrote:
The patch applies against master (a13f12b3a18da0a61571cb134fdecea03a10d6f)
However initdb fails with:
FATAL: return type mismatch in function declared to return record
DETAIL: Function's final statement must be SELECT or INSERT/UPDATE/DELETE
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 7, 2010 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In the particular case here, the dictionary structures could probably
safely use such a context type, but I'm not sure it's worth bothering
if the long-term plan is to implement a
2010/10/4 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
DEFAULT is disallowed now in such VALUES list, but we can explain it
is allowed in a simple VALUES of INSERT case.
I don't think we really need to explain anything. This is per spec;
if you trace the way that
On Oct 3, 2010, at 11:10 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
DEFAULT is disallowed now in such VALUES list, but we can explain it
is allowed in a simple VALUES of INSERT case.
I don't think we really need to explain anything. This is per spec;
On Oct 3, 2010, at 7:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's not at all apparent that the code is even
safe as-is, because it's depending on the unstated assumption that that
static variable will get reset once per dictionary. The documentation
is horrible: it doesn't really explain
On Mon, 4 Oct 2010, Marko Tiikkaja wrote:
On 2010-10-03 5:08 AM +0300, Steve Singer wrote:
Hmm.. I can't reproduce this. What platform are you on?
Sorry, I it seems the changes to one file (pg_proc.c) didn't get applied to
my source repository. Now that I've applied them initdb works
On Sat, Oct 2, 2010 at 9:36 AM, Josh Kupershmidt schmi...@gmail.com wrote:
Hrm, this is interesting. I set up a test table with 5M rows like so:
Such discussions are for the planner itself, right? The sorted cluster
patch uses the existing planner's costing model, so we can discuss the
21 matches
Mail list logo
