Tom Lane [EMAIL PROTECTED] wrote:
The other patch was ITAGAKI Takahiro's patch to fix n_dead_tuples in
pgstats after VACUUM when there is concurrent update activity.
I objected (and still object) to this patch because it allows
n_dead_tuples to drift arbitrarily far away from reality
Tom Lane írta:
...
If anyone seriously wants to propose removing postfix ops from b_expr,
we'd better take it up on someplace more widely read than -patches.
regards, tom lane
OK, I take the bullet and send it to -hackers.
For everyone who don't read -patches, let
Hi,
Alvaro Herrera wrote:
Which is not always what happens in reality. Consider for example that
we borrowed some files from NetBSD, OpenBSD, Tcl, zic and others. It
would be nice to know exactly at what point we borrowed the file, so we
can go to the upstream repo and check if there's any
Hi
Jim C. Nasby wrote:
I understand the argument about metadata and all, and largely agree with
it. But on the other hand I think a version identifier is a critical
piece of information; it's just as critical as the file name when it
comes to identifying the information contained in the file.
Hello,
I would like to submit a patch so that the
COPY statement can import data into a view.
(Maybe if this works I'll see about copying
out of a view.)
Rather than spend a whole lot of time figuring
out all the calls to use and all the detail,
I'm going to go ahead and post now. That way
if
On 04/19/2007 08:41:55 AM, Karl O. Pinc wrote:
I would like to submit a patch so that the
COPY statement can import data into a view.
2) Allocate memory for char* and construct an
'INSERT ...' statement corresponding
to the COPY command that inserts into the view.
(Just how much memory
Karl O. Pinc wrote:
(Maybe if this works I'll see about copying
out of a view.)
You know we already have
COPY (SELECT ...) TO ...
don't you?
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Karl O. Pinc wrote:
On 04/19/2007 08:41:55 AM, Karl O. Pinc wrote:
I would like to submit a patch so that the
COPY statement can import data into a view.
2) Allocate memory for char* and construct an
'INSERT ...' statement corresponding
to the COPY command that inserts into the view.
Karl O. Pinc [EMAIL PROTECTED] writes:
Rather than spend a whole lot of time figuring
out all the calls to use and all the detail,
I'm going to go ahead and post now. That way
if this is simply not going to fly I don't have
to spend any more time on it. Otherwise,
I'll post more as I work
On 04/19/2007 09:33:44 AM, Andrew Dunstan wrote:
Karl O. Pinc wrote:
(Maybe if this works I'll see about copying
out of a view.)
You know we already have
COPY (SELECT ...) TO ...
don't you?
Sure. It'd just be syntatic suger for the
COPY (SELECT ...) form, so end-users
don't have to
On 04/19/2007 09:39:18 AM, Alvaro Herrera wrote:
I'm not sure the plan is OK as stated. You wouldn't want to force to
parse the query again for each row. Rather, create a prepared
statement
(already parsed, because you obtain it from the parsetree stored in
the
INSERT rule) to pass to the
Jim C. Nasby wrote:
Then how do you tell what version a file is if it's outside of a
checkout?
It's trivial for git to answer that - the file will either be pristine,
and then we can just scan for the matching SHA1, or modified, and we can
scan (taking a weee bit more time) which are the
Jim C. Nasby wrote:
Not bad... took you 40 lines to answer my question. Let's see if I can
beat that...
Sure - it'll be 1 line when it's wrapped in a shell script. And then
we'll be even.
I understand the argument about metadata and all, and largely agree with
it. But on the other hand I
Gregory Stark wrote:
Karl O. Pinc [EMAIL PROTECTED] writes:
Rather than spend a whole lot of time figuring
out all the calls to use and all the detail,
I'm going to go ahead and post now. That way
if this is simply not going to fly I don't have
to spend any more time on it.
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
There are also
some interesting questions about SQL spec compliance and whether a
database that silently hides some rows from you will give semantically
consistent results.
Yeah -- that's a potentially serious issue; KaiGai, have you
Karl O. Pinc wrote:
On 04/19/2007 09:39:18 AM, Alvaro Herrera wrote:
I'm not sure the plan is OK as stated. You wouldn't want to force to
parse the query again for each row. Rather, create a prepared
statement
(already parsed, because you obtain it from the parsetree stored in
the
I am seeing the following compiler warnings in CVS HEAD:
analyze.c:471: warning: `diff' might be used uninitialized in this
function
vacuumlazy.c:220: warning: `diff' might be used uninitialized in this
function
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
Bruce Momjian wrote:
I am seeing the following compiler warnings in CVS HEAD:
analyze.c:471: warning: `diff' might be used uninitialized in this
function
vacuumlazy.c:220: warning: `diff' might be used uninitialized in this
function
Are you using too old a compiler? Mine
Alvaro Herrera wrote:
Bruce Momjian wrote:
I am seeing the following compiler warnings in CVS HEAD:
analyze.c:471: warning: `diff' might be used uninitialized in this
function
vacuumlazy.c:220: warning: `diff' might be used uninitialized in this
function
Are you using
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
I am seeing the following compiler warnings in CVS HEAD:
analyze.c:471: warning: `diff' might be used uninitialized in this
function
vacuumlazy.c:220: warning: `diff' might be used uninitialized in this
Hello,
in doc there are for returned value:
SPI_processed and SPI_tuptable are set as in SPI_execute if successful.
But for move statement is SPI_tuptable undefined. Move statement only move
cursor. Doesn't return anything.
Regards
Pavel Stehule
Hello,
I found one unsupported form plpgsql's fetch statement which is supported
by postgresql.
PostgreSQL knows
FETCH 3 FROM
but plpgsql needs everytime direction's keyword. It's need small fix. I am
sorry.
Regards
Pavel Stehule
Hi
I believe I have discovered the following problem in pgsql 8.2 and HEAD,
concerning warm-standbys using WAL log shipping.
The problem is that after a crash, the master might complete incomplete
actions via rm_cleanup() - but since it won't wal-log those changes,
the slave won't know about
On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote:
The problem comes from cases like
colname coltype DEFAULT 5! GENERATED ...
Since b_expr allows postfix operators, it takes one more token of
lookahead than we have to tell if the default expression is 5!
or
Hello people,
I'm thinking in project and implement data fragmentation based on
catalogs inside
pgcluster as my university final project. I would like suggestions and
would be happy if anyone help me to define it. Sorry if this is the
incorrect list...I had no answer on pgcluster-general...
Stephen Frost wrote:
While I agree that raising a warning makes sense I don't believe it
should be forced. There may be cases where, even in security definer
functions, the current search_path should be used (though, of course,
care must be taken in writing such functions).
I really wonder
Alvaro Herrera [EMAIL PROTECTED] writes:
The threads to updatable views have concluded rejecting the patches, and
with ideas that require rather extensive rewriting of the rule manager,
I have some ideas on a different approach to this if anyone's thinking of
starting fresh but I had the
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The threads to updatable views have concluded rejecting the patches, and
with ideas that require rather extensive rewriting of the rule manager,
I have some ideas on a different approach to this if anyone's thinking of
On Thursday 05 April 2007 16:28, Larry Rosenman wrote:
I might use that as the base then, since the hardware finishes getting here
tomorrow.
My question still stands on what OS's we need coverage for.
One I see as missing right now is Solaris 10 X86 with gcc building 64bit
binaries (we have
Alvaro Herrera [EMAIL PROTECTED] writes:
What ideas?
Basically I think what we should do is extend SQL to support things like
UPDATE (subquery) SET ...
DELETE FROM (subquery) WHERE ...
Ie, do the update-able view magic in the planner and executor rather than in
the rewriter. Then the
Gustavo Tonini wrote:
I'm thinking in project and implement data fragmentation based on
catalogs inside
pgcluster as my university final project. I would like suggestions and
would be happy if anyone help me to define it. Sorry if this is the
incorrect list...I had no answer on
Pavel Stehule [EMAIL PROTECTED] writes:
I found one unsupported form plpgsql's fetch statement which is supported
by postgresql.
PostgreSQL knows
FETCH 3 FROM
but plpgsql needs everytime direction's keyword.
No, I think that's OK, because that form specifies fetching 3 rows,
which
Pavel Stehule [EMAIL PROTECTED] writes:
I found one unsupported form plpgsql's fetch statement which is
supported
by postgresql.
PostgreSQL knows
FETCH 3 FROM
but plpgsql needs everytime direction's keyword.
No, I think that's OK, because that form specifies fetching 3 rows,
33 matches
Mail list logo
