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
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 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
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 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 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
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 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
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 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
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 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
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 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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> At the moment, user-accessible RULEs have, as far as I know,
> just two sane uses:
>
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
> 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
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
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:
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
>
> "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'
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
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
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
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
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, 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
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 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
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
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
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
>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
* 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
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
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
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
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
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
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 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
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.
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
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
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
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
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
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
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
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 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.
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
* 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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
> "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
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
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
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
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
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 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
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, 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
81 matches
Mail list logo
