It appears that the patch here:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=a30fa4ca33d055c46bebc0e5c701d5b4fd27814d
missed adding PGC_S_DATABASE_USER to a few locations, most notably
GucSource_Names, where the PGC_S_SESSION now points off the end of the
array.
Patch attached.
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_iso
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_isolati
Josh Berkus 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 variables
because we c
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
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 next
David Fetter 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
> F
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 (
SELE
2009/10/13 Tom Lane :
> 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 well. What I am
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
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 /home/kaigai/RPMS/SOURCES/sepgsql-02-blob-8.5devel-
Magnus Hagander 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 always fail if r
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 use
Jaime Casanova writes:
> On Mon, Oct 12, 2009 at 1:42 PM, Tom Lane 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 ;)
Done.
Petr Jelinek 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:
http://www.postgresql.
On Mon, Oct 12, 2009 at 1:42 PM, Tom Lane 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,
Jaime Casanova
Sopor
Itagaki Takahiro wrote:
Andrew Dunstan 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 that hard to do?
Simon Riggs 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 if a row that
>>
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 t
Petr Jelinek 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 IN SCHEMA" wouldn't
On Mon, Oct 12, 2009 at 1:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane 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
Robert Haas writes:
> On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane 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 worse plan, and second because
>
On Mon, Oct 12, 2009 at 11:31:24AM -0400, Robert Haas wrote:
> 2009/10/12 Teodor Sigaev :
> >> 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 b
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 values
2009/10/12 Teodor Sigaev :
>> 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 planner. I
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 w
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 backe
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
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)
On Thu, 2009-10-08 at 11:50 -0400, Tom Lane wrote:
> Robert Haas 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 been following t
30 matches
Mail list logo
