On Mon, 2009-10-05 at 18:30 -0400, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2009-09-28 at 11:25 +0300, Heikki Linnakangas wrote:
> >> Heikki Linnakangas wrote:
> >>> Per Simon's request, for the benefit of the archive, here's all the
> >>> changes I've done on the patch since he
I tried to check the default ACL behavior.
postgres=# \c - ymj
psql (8.5devel)
You are now connected to database "postgres" as user "ymj".
postgres=> ALTER DEFAULT PRIVILEGES REVOKE INSERT ON TABLE FROM ymj;
ALTER DEFAULT PRIVILEGES
postgres=> CREATE TABLE t2 (x int, y text);
CREATE
On Mon, Oct 5, 2009 at 10:17 AM, Josh Berkus wrote:
> So while rules are hard to use and easy to mess up, so are triggers. So
> while an (arguable) problem is being pointed out, no real solution is
> being proposed.
If you want to implement updatable views I still stand by my (much)
earlier desi
Jaime Casanova writes:
> seems like the original idea was to forbid this in all system catalogs
> except pg_largeobject, what happen then?
Nothing ... nobody got around to doing anything about it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Mon, Oct 5, 2009 at 7:15 PM, Euler Taveira de Oliveira
wrote:
>>
>> db=# alter table pg_largeobject set tablespace otro;
>> ERROR: permission denied: "pg_largeobject" is a system catalog
>>
>
> [1] http://archives.postgresql.org/pgsql-hackers/2004-06/msg00835.php
seems like the original idea
Fujii Masao escreveu:
> On Tue, Oct 6, 2009 at 7:47 AM, Heikki Linnakangas
> wrote:
>> That TODO item is a lot less important after we have Hot Standby. It
>> contains functions that allow you to pause and continue WAL replay, and
>> step through the WAL one transaction at a time.
>
> I don't thi
Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> So what's the status of this patch currently?
>
> I'll be reviewing the updates shortly. After that, I'd like a committer
> to review it.
Do you think this version also should rework an invocation of
pg_namespace_aclcheck() n
I rebased the largeobject access controls patch to the CVS HEAD
because of the patch confliction to the default ACL patch.
The only difference was a switch-case statement was moved from
shdepDropOwned() to RemoveRoleFromObjectACL(), so we had to
change the point to be patched.
I don't think this
> "Josh" == Josh Berkus writes:
>> 1) any reference in an insert rule to NEW.col where col has a volatile
>> default, or the expression in the insert statement was volatile, or
>> the expression's value is changed by the insert, will do the wrong
>> thing:
Josh> Is this different from t
There are now 19 patches out of an original total of 48 to be dealt
with for this CommitFest. Of those, 10 are marked as "Ready for
Committer", 1 is marked as "Needs Review" and the listed reviewer is a
committer, 7 are waiting for review or re-review by non-committers,
and 1 is waiting on the pat
Robert Haas wrote:
> On Mon, Oct 5, 2009 at 1:46 PM, Joe Conway wrote:
>> I can't promise to make this change before 15 October, but I will get to
>> it before the end of CF3.
>
> Another possibility is that Itagaki Takahiro, who developed the
> original patch, might be willing to develop somethi
Hi,
On Tue, Oct 6, 2009 at 7:47 AM, Heikki Linnakangas
wrote:
> That TODO item is a lot less important after we have Hot Standby. It
> contains functions that allow you to pause and continue WAL replay, and
> step through the WAL one transaction at a time.
I don't think this is practical for PIT
On Sun, Oct 4, 2009 at 4:14 PM, Jeff Janes wrote:
> On Mon, Sep 28, 2009 at 12:14 AM, Jaime Casanova
> wrote:
>> On Sat, Aug 8, 2009 at 7:47 PM, Mark Kirkwood wrote:
>
>
Patch with max(wait time).
Still TODO
- amalgamate individual transaction lock waits
- r
On Mon, Oct 5, 2009 at 1:46 PM, Joe Conway wrote:
> Tom Lane wrote:
>> Itagaki Takahiro writes:
>>> I think PG_TRY blocks are not enough, too. PG_TRY requires a statement
>>> block, but we need to return from dblink functions per tuple.
>>
>> That bit will have to be undone. There is no reason f
Jaime Casanova escreveu:
> it seems like we can't do this. At least a get this error:
>
> db=# alter table pg_largeobject set tablespace otro;
> ERROR: permission denied: "pg_largeobject" is a system catalog
>
> but pg_largeobject seems sensible to move to another table space for
> space conside
2009/10/6 Tom Lane :
> Brendan Jurd writes:
>> I pulled the latest sources and gave it a whirl. Things worked as
>> expected in psql, but I was a little surprised when I headed into the
>> documentation. The first place I visited was Chapter 20 - Database
>> Roles and Privileges, but there was n
Jaime Casanova writes:
> it seems like we can't do this. At least a get this error:
> db=# alter table pg_largeobject set tablespace otro;
> ERROR: permission denied: "pg_largeobject" is a system catalog
You can move *all* of the system catalogs with ALTER DATABASE SET
TABLESPACE. pg_largeobje
Hi,
it seems like we can't do this. At least a get this error:
db=# alter table pg_largeobject set tablespace otro;
ERROR: permission denied: "pg_largeobject" is a system catalog
but pg_largeobject seems sensible to move to another table space for
space considerations, no? are there any reasons
Tom Lane napsal(a):
Petr Jelinek writes:
Tom Lane napsal(a):
One thing that seems like it's likely to be an annoyance in practice
is the need to explicitly do DROP OWNED BY to get rid of pg_default_acl
entries for a role to be dropped.
Yeah I am not happy about this either but t
Brendan Jurd writes:
> I pulled the latest sources and gave it a whirl. Things worked as
> expected in psql, but I was a little surprised when I headed into the
> documentation. The first place I visited was Chapter 20 - Database
> Roles and Privileges, but there was no mention of the default AC
Petr Jelinek writes:
> Tom Lane napsal(a):
>> One thing that seems like it's likely to be an annoyance in practice
>> is the need to explicitly do DROP OWNED BY to get rid of pg_default_acl
>> entries for a role to be dropped.
> Yeah I am not happy about this either but there is not much we can d
shakahsha...@gmail.com wrote:
> Can anyone elaborate (or point me to some additional info) on the 8.5
> TODO item in the "Point-In-Time Recover (PITR) section (1.4)":
> Create dump tool for write-ahead logs for use in determining
> transaction id for point-in-time recovery
> This is useful f
Tom Lane napsal(a):
Petr Jelinek writes:
[ latest default-ACLs patch ]
Applied with a fair amount of editorial polishing. Notably I changed
the permissions requirements a bit:
Thank you very much Tom.
One thing that seems like it's likely to be an annoyance in practice
is the
Simon Riggs wrote:
> On Mon, 2009-09-28 at 11:25 +0300, Heikki Linnakangas wrote:
>> Heikki Linnakangas wrote:
>>> Per Simon's request, for the benefit of the archive, here's all the
>>> changes I've done on the patch since he posted the initial version for
>>> review for this commitfest as increme
Simon Riggs wrote:
> We discussed briefly your change
> 0011-Replace-per-proc-counters-of-loggable-locks-with-per.patch.
>
> I don't see how that helps at all. The objective of lock counters was to
> know if we can skip acquiring an LWlock on all lock partitions. This
> change keeps the lock coun
* Robert Haas (robertmh...@gmail.com) wrote:
> So what's the status of this patch currently?
I'll be reviewing the updates shortly. After that, I'd like a committer
to review it.
Thanks,
Stephen
signature.asc
Description: Digital signature
2009/10/6 Tom Lane :
> Applied with a fair amount of editorial polishing. Notably I changed
> the permissions requirements a bit:
>
Thanks and congratulations! I'm really looking forward to this feature.
I pulled the latest sources and gave it a whirl. Things worked as
expected in psql, but I
On Wed, Sep 30, 2009 at 11:17 PM, Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> Stephen Frost wrote:
>> > Thanks. To make sure it gets picked up, you might respond to Tom's
>> > message above with this same email. Just a thought.
>>
>> The following message was my reply.
Roger Leigh writes:
> On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
>> Elsewhere in the psql code, notably in mbprint.c, we make the decision
>> on whether to apply certain Unicode-aware processing based on whether
>> the client encoding is UTF8. The same should be done here.
On Mon, 2009-10-05 at 11:58 -0700, Josh Berkus wrote:
> Simon,
>
> > A small addition though, please. This functionality has been available
> > since 8.1 and changing things could cause existing people's scripts to
> > fail when they upgrade. If we make this change then we should make sure
> > th
Joe Conway writes:
> Tom Lane wrote:
>> No big hurry, I think, considering the leak has always been there.
> Great. It seems like this is too invasive a change to backport. My
> feeling is that not enough people have complained about this specific
> scenario to warrant the risk.
Agreed, the risk
Josh Berkus writes:
> On 10/3/09 8:09 AM, Kevin Grittner wrote:
>> Robert Haas wrote:
> let's let the default, global default ACL contain the hard-wired
> privileges, instead of making them hardwired.
> Wow, that would be great. It would meant that DBAs could change the
> global default permiss
On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> I have a comment on this bit:
>
> > @@ -125,6 +128,17 @@ main(int argc, char *argv[])
> >
> > /* We rely on unmentioned fields of pset.popt to start out
> > 0/false/NULL */
> > pset.popt.topt.format = PRINT_ALIGN
Petr Jelinek writes:
> [ latest default-ACLs patch ]
Applied with a fair amount of editorial polishing. Notably I changed
the permissions requirements a bit:
* for IN SCHEMA, the *target* role has to have CREATE permission on the
target schema. Without this, the command is a bit pointless sinc
Tom Lane wrote:
> Joe Conway writes:
>> Given that change, is there even any leak to even worry about? As long
>> as the PGresult object is created in the correct memory context, it
>> ought to get cleaned up automatically, no?
>
> No, because libpq knows nothing of backend memory contexts; it ju
Simon,
> A small addition though, please. This functionality has been available
> since 8.1 and changing things could cause existing people's scripts to
> fail when they upgrade. If we make this change then we should make sure
> that explicitly GRANTing a permission on the child tables does not fa
Joe Conway writes:
> Given that change, is there even any leak to even worry about? As long
> as the PGresult object is created in the correct memory context, it
> ought to get cleaned up automatically, no?
No, because libpq knows nothing of backend memory contexts; it just
allocates with malloc.
On Mon, 2009-10-05 at 10:19 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > I don't see how that helps at all. The objective of lock counters was to
> > know if we can skip acquiring an LWlock on all lock partitions. This
> > change keeps the lock counters yet acquires the locks we were trying t
On Mon, 2009-10-05 at 10:27 -0700, Josh Berkus wrote:
> Simon,
>
> >> We could use a GUC variable to ease the transition, perhaps like
> >> sql_inheritance = no | yes_without_privileges | yes
> >
> > The original way of doing things was quite useful if you wanted some
> > people to be able to se
On Mon, 2009-10-05 at 11:45 +0100, Simon Riggs wrote:
> On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
> > On Mon, 2009-10-05 at 10:47 +0100, Simon Riggs wrote:
> > > top level: data-template
> > > main tables: data, data-recent both inherit from data-template
> > > all partitions inher
Tom Lane wrote:
> Itagaki Takahiro writes:
>> I think PG_TRY blocks are not enough, too. PG_TRY requires a statement
>> block, but we need to return from dblink functions per tuple.
>
> That bit will have to be undone. There is no reason for dblink not to
> return a tuplestore.
That's a really
Simon,
>> We could use a GUC variable to ease the transition, perhaps like
>> sql_inheritance = no | yes_without_privileges | yes
>
> The original way of doing things was quite useful if you wanted some
> people to be able to see history and others just see recent data. I
> don't think many peopl
Andrew,
> 1) any reference in an insert rule to NEW.col where col has a volatile
>default, or the expression in the insert statement was volatile, or
>the expression's value is changed by the insert, will do the wrong
>thing:
Is this different from triggers?
> 2) any rule with multip
Emmanuel,
> I think that this was the original idea but we should probably rollback
> the error logging if the command has been rolled back. It might be more
> consistent to use the same hi_options as the copy command. Any idea what
> would be best?
Well, if we're logging to a file, you wouldn't
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> >Stephen Frost wrote:
> > Do we have a patch which implements the necessary mechanics to
> > replace RULEs, even for the specific situations you list? Until
> > then, I don't think there's much to discuss.
>
> I thought that until we had d
>Stephen Frost wrote:
> Do we have a patch which implements the necessary mechanics to
> replace RULEs, even for the specific situations you list? Until
> then, I don't think there's much to discuss.
I thought that until we had discussion and consensus it was premature
to start working on a p
On Mon, Oct 05, 2009 at 11:28:13AM -0400, Alvaro Herrera wrote:
> Dan Colish wrote:
> > On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
> > > On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
>
> > > > You can definitely create updatable views using rules.
> > >
> > > Sure y
2009/10/5 Dan Colish :
> On Mon, Oct 05, 2009 at 11:28:13AM -0400, Alvaro Herrera wrote:
>> Dan Colish wrote:
>> > On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
>> > > On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
>>
>> > > > You can definitely create updatable views usi
On Mon, Oct 05, 2009 at 11:28:13AM -0400, Alvaro Herrera wrote:
> Dan Colish wrote:
> > On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
> > > On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
>
> > > > You can definitely create updatable views using rules.
> > >
> > > Sure y
Hi Selena,
This is my first pass at the error logging portion of this patch. I'm
going to take a break and try to go through the partitioning logic as
well later this afternoon.
caveat: I'm not familiar with most of the code paths that are being
touched by this patch.
Overall:
* I noticed '\se
Dan Colish wrote:
> On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
> > On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
> > > You can definitely create updatable views using rules.
> >
> > Sure you can, but they won't work in various significant corner cases.
> >
> > Sear
On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
> On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
> > I am not sure where that view implemenation is, but I doubt its
> > stalled because of the rule system.
>
> It is.
>
> > You can definitely create updatable views using ru
On Sun, Oct 4, 2009 at 10:28 PM, Fujii Masao wrote:
> I think that xlogdump (http://xlogviewer.projects.postgresql.org/) is
> the first step to address that TODO item. Though I'm not sure if the
> xlogdump project is still active.
>
I believe it has been dead for quite awhile now. Though, Tom m
On Mon, Oct 05, 2009 at 10:32:53AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > WITH NEW AS (
> > insert into t values (floor(random()*1000)::integer);
> > RETURNING *
> > )
> > insert into t_log values (NEW.a);
>
> > Would this not have the required semantics?
>
> Interestin
Martijn van Oosterhout writes:
> ISTM it may be possible to use the new WITH construct here. So the rule
> evaluation for the following
>> create table t (a integer);
>> create table t_log (a integer);
>> create rule t_ins AS ON insert TO t do also insert into t_log values (NEW.a);
>> insert into
On Mon, 2009-10-05 at 10:14 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
> >> I don't see where the problem is here.
>
> > In your last post you said it was necessary to use ONLY to address the
> > required partitions and so setup wo
Simon Riggs writes:
> I don't see how that helps at all. The objective of lock counters was to
> know if we can skip acquiring an LWlock on all lock partitions. This
> change keeps the lock counters yet acquires the locks we were trying to
> avoid. This change needs some justification since it is
Simon Riggs writes:
> On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
>> I don't see where the problem is here.
> In your last post you said it was necessary to use ONLY to address the
> required partitions and so setup would be weird. I am showing that this
> is not required and the s
On Mon, Oct 05, 2009 at 02:53:56PM +0100, Andrew Gierth wrote:
> Here are a couple of the more common ones:
>
> 1) any reference in an insert rule to NEW.col where col has a volatile
>default, or the expression in the insert statement was volatile, or
>the expression's value is changed by
> "Greg" == "Greg Sabino Mullane" writes:
>> They're mostly a foot-gun.
Greg> Lots of things in Postgres could be considered potential foot
Greg> guns. Frankly, I don't think rules are even near the top of
Greg> such a list. Can you give examples of rule foot guns?
There are so many it'
Jeff Janes writes:
> Do you know why that should be? I've done some work with gprof, and
> the results are pretty suspect, because the total gprof time adds up
> to only about 1/3 of the total time the backend spends on CPU
> (according to "top"), and I don't know where the unaccounted for time
>
VER window
(which the spec does allow)
Requires initdb. Beware of bugs. Slippery when wet.
--
Andrew (irc:RhodiumToad)
aorder-20091005.patch.gz
Description: aggregate ordering patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Andrew Dunstan wrote:
> We have this para in the CREATE TABLE docs, commented out
> Surely we should either include it or remove it.
+1
If it's deleted, it'll still be in CVS history if someone wants it
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
> By chance I noticed that the foreign_data regression test fails if run
> in an installation where "bob" is a live user. It appears to be
> assuming that half a dozen other fairly common names don't belong to
> real users, either. Could we make this a little less fragile? Maybe
Attached is a p
Greg Sabino Mullane wrote:
> Could this be done with a trigger? Yes, but on the plus rules side:
>
> * It's faster
> * It's easier to write
> * It's immediately viewable as to what is going on with a \d mytable
> * Dropping it won't leave an unused function around
> * We can still do ALTER TABLE D
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> At the moment, user-accessible RULEs have, as far as I know,
> just two sane uses:
>
Hi,
thank you very much for the review.
Noah Misch írta:
> I took a look at 2-pg85-sqlda-10-ctxdiff.patch. Starting from CVS HEAD of
> roughly 2009-10-03 05:00 UTC, prerequisite patches 1a-1h applied cleanly.
> 2-pg85-sqlda hit a trivial whitespace reject in ecpg.trailer along with a more
> subs
On Sun, 2009-09-27 at 13:57 +0300, Heikki Linnakangas wrote:
> Per Simon's request, for the benefit of the archive, here's all the
> changes I've done on the patch since he posted the initial version for
> review for this commitfest as incremental patches. This is extracted
> from my git repositor
On Mon, 2009-09-28 at 11:25 +0300, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > Per Simon's request, for the benefit of the archive, here's all the
> > changes I've done on the patch since he posted the initial version for
> > review for this commitfest as incremental patches. This is
On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
> On Mon, 2009-10-05 at 10:47 +0100, Simon Riggs wrote:
> > top level: data-template
> > main tables: data, data-recent both inherit from data-template
> > all partitions inherit from data
> > only recent partitions inherit from data-recen
Tom Lane writes:
> In cases where you do have related functions, I suggest having
> SQL-callable V1 functions that absorb their arguments in this
> style, and then have them call a common subroutine that's a plain
> C function.
Unless you have high performance requirements, IME. Avoiding the SQL
On Mon, 2009-10-05 at 10:47 +0100, Simon Riggs wrote:
> top level: data-template
> main tables: data, data-recent both inherit from data-template
> all partitions inherit from data
> only recent partitions inherit from data-recent
> grants are issued on data and data-recent
I don't see where the p
On Mon, 2009-10-05 at 12:30 +0300, Peter Eisentraut wrote:
> On Mon, 2009-10-05 at 09:22 +0100, Simon Riggs wrote:
> > On Sat, 2009-10-03 at 09:45 +0300, Peter Eisentraut wrote:
> >
> > > We could use a GUC variable to ease the transition, perhaps like
> > > sql_inheritance = no | yes_without_pri
On Mon, 2009-10-05 at 09:22 +0100, Simon Riggs wrote:
> On Sat, 2009-10-03 at 09:45 +0300, Peter Eisentraut wrote:
>
> > We could use a GUC variable to ease the transition, perhaps like
> > sql_inheritance = no | yes_without_privileges | yes
>
> The original way of doing things was quite useful i
Peter Eisentraut wrote:
> On Mon, 2009-10-05 at 16:27 +0900, KaiGai Kohei wrote:
>> CREATE TABLE tbl_p (int a, int b);
>> CREATE TABLE tbl_c (int x) INHERITS(tbl_p);
>>
>> SELECT a,b FROM tbl_p; --> It selects data from only tbl_p.
>> It is reasonable to bypass checks o
--On 4. Oktober 2009 21:37:45 -0400 Robert Haas
wrote:
This is the last I remember hearing of it, which seems to suggest that
only a week's worth of work (maybe a bit more for those of us who are
not Tom Lane) is needed:
http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php
Bu
--On 5. Oktober 2009 09:51:29 +0300 Peter Eisentraut
wrote:
The way forward with updatable views is triggers on views. I was going
to write something about that in the future. I haven't worked out all
the details.
In the mentioned discussion there was already the notion of "substitution
On Mon, 2009-10-05 at 16:27 +0900, KaiGai Kohei wrote:
> CREATE TABLE tbl_p (int a, int b);
> CREATE TABLE tbl_c (int x) INHERITS(tbl_p);
>
> SELECT a,b FROM tbl_p; --> It selects data from only tbl_p.
> It is reasonable to bypass checks on tbl_c.
> SELECT b,x FROM tbl
On Sat, 2009-10-03 at 09:45 +0300, Peter Eisentraut wrote:
> We could use a GUC variable to ease the transition, perhaps like
> sql_inheritance = no | yes_without_privileges | yes
The original way of doing things was quite useful if you wanted some
people to be able to see history and others jus
Peter Eisentraut wrote:
> On Mon, 2009-10-05 at 12:15 +0900, KaiGai Kohei wrote:
>> On the other hand, it also needs to check permission both of child
>> table and its parents when we select data from a table with its
>> parents,
>
> You can't do that anyway.
Sorry, I'm not clear why it is imposs
On Mon, 2009-10-05 at 12:15 +0900, KaiGai Kohei wrote:
> On the other hand, it also needs to check permission both of child
> table and its parents when we select data from a table with its
> parents,
You can't do that anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
81 matches
Mail list logo
