I wrote:
Following the discussions in
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
and
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php ,
here are patches for
a) a hook in backend/commands/user.c that allows one to add
password checking functions
On Thu, 2009-10-08 at 11:50 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Subcommitting every single row is going to be really painful,
especially after Hot Standby goes in and we have to issue a WAL record
after every 64 subtransactions (AIUI).
Yikes ... I had not
On Thu, 2009-10-08 at 11:01 -0400, Tom Lane wrote:
So as far as I can see, the only form of COPY error handling that
wouldn't be a cruel joke is to run a separate subtransaction for each
row, and roll back the subtransaction on error. Of course the
problems
with that are (a) speed, (b) the
Are you planning to submit this as a /contrib module?
I haven't objections to do that, we don't planned that because we know sceptical
relation of community to hints :)
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Teodor Sigaev wrote:
Are you planning to submit this as a /contrib module?
I haven't objections to do that, we don't planned that because we know
sceptical
relation of community to hints :)
Well, the nice thing about this patch is that the hints are mostly
external to the backend, and
hi there ...
for this work i will include you in my evening prayers for at least one
week.
i know there has been a lot of discussion about this but what you just
posted it excellent and more important: USEFUL to many people.
i had something else in mind recently as well: virtual indexes. it
2009/10/12 Teodor Sigaev teo...@sigaev.ru:
Are you planning to submit this as a /contrib module?
I haven't objections to do that, we don't planned that because we know
sceptical
relation of community to hints :)
I think it would be pretty useful to have some additional knobs to
poke at the
While fooling around with moving FOR UPDATE into a plan node (WIP
version attached), I came across this interesting behavior:
1. Create test tables:
create table t1(f1 int, f2 int);
insert into t1 values (1,1);
insert into t1 values (2,2);
create table t2(f3 int, f4 int);
insert into t2
On Mon, Oct 12, 2009 at 11:31:24AM -0400, Robert Haas wrote:
2009/10/12 Teodor Sigaev teo...@sigaev.ru:
Are you planning to submit this as a /contrib module?
I haven't objections to do that, we don't planned that because we
know sceptical relation of community to hints :)
I think it
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Of course the downside of changing it is that queries that worked fine
before might work differently (and much slower) now; first because not
flattening the sub-select might lead to a
On Mon, Oct 12, 2009 at 1:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Of course the downside of changing it is that queries that worked fine
before might work differently (and much
Petr Jelinek pjmo...@pjmodos.net writes:
[ latest GRANT ALL patch ]
I started looking at this, and the first thing I noticed was that it
adds TABLES, FUNCTIONS, and SEQUENCES as unreserved keywords. Now
I'm not a fan of bloating the parser that way, but I have to admit
that GRANT ON ALL TABLE
On Mon, 2009-10-12 at 11:42 -0400, Tom Lane wrote:
The problem is that execMain.c is set up to pull as many rows as it can
from execution of an EvalPlanQual query. Then, once that's exhausted,
it steps to the next result from the original query. So if a row that
requires locking joins to
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-10-12 at 11:42 -0400, Tom Lane wrote:
The problem is that execMain.c is set up to pull as many rows as it can
from execution of an EvalPlanQual query. Then, once that's exhausted,
it steps to the next result from the original query. So
Itagaki Takahiro wrote:
Andrew Dunstan and...@dunslane.net wrote:
I'm wondering why we are not
copying comments on cloned indexes. I realize that might involve a bit
more code, but I think I'd feel happier if we cloned all the comments we
reasonably could from the outset. Is it really
On Mon, Oct 12, 2009 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ALTER DEFAULT PRIVILEGES ... GRANT ... ON TABLES TO ...
this makes sense to me, because you want the default to affect all new
tables not only a new single table.
so, as someone once told, +1 from me ;)
--
Atentamente,
Petr Jelinek pjmo...@pjmodos.net writes:
[ GRANT ON ALL ]
Applied with minor editorialization (mainly changing some choices
of identifiers)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Jaime Casanova jcasa...@systemguards.com.ec writes:
On Mon, Oct 12, 2009 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ALTER DEFAULT PRIVILEGES ... GRANT ... ON TABLES TO ...
this makes sense to me, because you want the default to affect all new
tables not only a new single table.
so, as
Hi,
as discussed on -general, I'd like to propose that Post-
greSQL provides generate_series(DATE, DATE) and
generate_series(DATE, DATE, INT) functions by default.
They are merely syntactic sugar for
generate_series($1::TIMESTAMP, $2::TIMESTAMP[,
'$3 days'::INTERVAL])::DATE and can be used
Magnus Hagander mag...@hagander.net wrote:
One other question - you note that WriteConsoleW() could fail if
stderr is redirected. Are you saying that it will always fail when
stderr is redirected, or only sometimes? If ony sometimes, do you know
under which conditions it happens?
It will
The attached patch is the revised one for largeobejct access controls,
because it conflicted to the GRANT/REVOKE ON ALL xxx IN SCHEMA.
No other changes are here.
Please apply this one, instead of the older revision (r2354).
Thanks,
$ diffstat
Stephen, Thanks for your reviewing comments, although you have busy days.
Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Please review the new revision, Thanks,
In general, I'm pretty happy with this revision. You still have a
number of places where you have
2009/10/13 Tom Lane t...@sss.pgh.pa.us:
I started looking at this, and the first thing I noticed was that it
adds TABLES, FUNCTIONS, and SEQUENCES as unreserved keywords. Now
I'm not a fan of bloating the parser that way, but I have to admit
that GRANT ON ALL TABLE IN SCHEMA wouldn't read
Folks,
While working to write the Sieve of Eratosthenes using CTEs, I ran
across a strange error, namely that it appears I'm not allowed to nest
WITH. Is this a bug?
Cheers,
David.
WITH RECURSIVE t1(n) AS (
VALUES(2)
UNION ALL
SELECT n+1 FROM t1 WHERE n 1000
),
t2 (n, i) AS (
David Fetter da...@fetter.org writes:
WITH RECURSIVE t1(n) AS (
VALUES(2)
UNION ALL
SELECT n+1 FROM t1 WHERE n 1000
),
t2 (n, i) AS (
SELECT 2*n+2, 2
FROM t1 WHERE 2*n+2 = 1000
UNION ALL
WITH t3(k) AS (
SELECT max(i) FROM t2
)
SELECT k*n+k, k
We can skip writing WAL during COPY and CLUSTER if archive_mode is off,
but we don't use the skipping during tables rewrites in ALTER TABLE.
Also we don't use BulkInsertState there.
Is it possible to use WAL-skipping and BulkInsertState in ATRewriteTable() ?
If ok, I'll submit a patch for the
Hackers,
A slew of settings in postgresql.conf, including work_mem, search_path,
DateStyle, and about 80 others are effectively just defaults for new
connections, since they can be changed by any user.
However, for *two* settings, and two settings only, we distinguish that
by naming an identical
Josh Berkus j...@agliodbs.com wrote:
default_transaction_isolation
default_transaction_read_only
They are settings of transaction_isolation and transaction_read_only
for *next* transactions, no?
transaction_isolation
transaction_read_only
Non-default versions are almost read-only
On Mon, 2009-10-12 at 22:13 -0700, Josh Berkus wrote:
However, for *two* settings, and two settings only, we distinguish that
by naming an identical setting default_* in postgresql.conf. This is
confusing and inconsistent with the rest of the GUCS. Namely:
default_transaction_isolation
Itagaki-san,
BEGIN;
SET transaction_isolation = 'serializable';
SET default_transaction_isolation = 'read committed';
SHOW transaction_isolation;
= serializable
SHOW default_transaction_isolation;
= read committed
COMMIT;
-- next transaction uses default_transaction_isolation
30 matches
Mail list logo
