On Sun, 2009-10-04 at 20:54 -0400, Alvaro Herrera wrote:
> While I don't agree with David Fetter's premise, I think rehashing how
> we handle VIEWs would be a good step towards updatable views. Right
> now, the implementation of that is stalled precisely because of the rule
> system.
The way forw
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 rules.
Sure you can, but they won't work in various significant corner cases.
Se
On Sun, Oct 4, 2009 at 7:13 PM, Tom Lane wrote:
> Jeff Janes writes:
>
>> I've played around a bit with hash indexes, and it seems to me that
>> making them generally worthwhile will take (at least) reducing or
>> entirely doing away with the heavy-wait locks.
>
> Concurrency is really the least
Here is an update version of buffer usage patch.
* All buffers_* and bufs_* are renamed to blks_*.
* 'disc' => 'disk' in documentation
* Replace debug-log to Assert().
* Fix a bug in ResetLocalBufferUsage(). log_xxx_stats had not worked.
Robert Haas wrote:
> > ?* Can I use "temp" instead
On Sun, Oct 4, 2009 at 11:22 PM, Itagaki Takahiro
wrote:
> Robert Haas wrote:
>
>> 1. I would suggest something like "Blocks
>> Read: %ld Hit: %ld Temp Read: %ld\n". See the way we handle output
>> of sort type and space usage, for example.
>
> I have some questions:
> * Did you use single s
Robert Haas wrote:
> 1. I would suggest something like "Blocks
> Read: %ld Hit: %ld Temp Read: %ld\n". See the way we handle output
> of sort type and space usage, for example.
I have some questions:
* Did you use single space and double spaces in your example intentionally?
* Should we
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.
regards, tom lane
Peter Eisentraut wrote:
> I would like to propose a change in the way privilege checking is done
> with inheritance hierarchies. Currently, selecting from a table that
> has children requires explicit privileges on all the children. This is
> inconsistent with all other commands, which treat chil
Tom Lane wrote:
> I think what you want to do instead is use PG_TRY blocks to ensure that
> transient results are cleaned up.
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.
Error and interruption can occur at
Itagaki Takahiro writes:
> Joe Conway wrote:
>> Please see if this works for you.
> It does not work because errors can occur in caller of dblink functions;
> Error callback should be still registered after SRF_RETURN_NEXT, so we
> cannot place callback context on stack of the function. More wor
On Sun, Oct 4, 2009 at 10:01 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> > While I don't agree with David Fetter's premise, I think rehashing how
>> > we handle VIEWs would be a good step towards updatable views. Right
>> > now, the implementation of that is stalled precisely because o
Joe Conway wrote:
> > The point is *memory leak* in dblink when a query is canceled or
> > become time-out. I think it is a bug, and my patch could fix it.
>
> Please see if this works for you.
It does not work because errors can occur in caller of dblink functions;
Error callback should be st
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?
I found it is not so diff
Hi,
On Sat, Oct 3, 2009 at 7:30 AM, 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-
Jeff Janes writes:
> I see that the docs were recently changed from discouraging hash
> indexes both because they were no known uses in which they were
> meaningfully better than btree, and because they aren't recoverable;
> to now just discouraging them because they are not recoverable. Does
> t
The problem comes from the foo_malformed_terminator.data file.
It is supposed to have a malformed terminator that was not catch by
patch. The second line should look like:
2 two^M
If it does not, you can edit it with emacs, go at the end of the second
line and press Ctrl+q followed by Ctrl+m
Itagaki Takahiro writes:
> Peter Eisentraut wrote:
>> OK, but what you can do is point both variants to the same C function
>> and check with PG_NARGS() with how many arguments you were called. That
>> would save some of the indirections.
> The regressiontest 'opr_sanity' failed if do so. Shoul
Robert Haas escribió:
> > While I don't agree with David Fetter's premise, I think rehashing how
> > we handle VIEWs would be a good step towards updatable views. Right
> > now, the implementation of that is stalled precisely because of the rule
> > system.
>
> This is the last I remember hearin
Peter Eisentraut writes:
> On Sun, 2009-10-04 at 11:56 -0700, Josh Berkus wrote:
>> And we'd want to hammer this to death looking for ways it can be a
>> security exploit. Like, could you make a table into the parent of an
>> existing table you didn't have permissions on?
> I don't think so, but
On Sun, Oct 4, 2009 at 8:54 PM, Alvaro Herrera
wrote:
> David E. Wheeler wrote:
>> On Oct 4, 2009, at 1:57 PM, David Fetter wrote:
>>
>> >It's less about like or dislike and more about facing up to the
>> >reality that we've got a major legacy foot-gun left over from the
>> >experimentation of the
Khee Chin wrote:
> Recently, I encountered a situation where the docs on (or impl?)
> INCLUDING INDEXES and INCLUDING CONSTRAINTS are not clearly defined
> for primary keys. Should it be noted in the docs that in this case, we
> are referring to the technical implementation of a primary key, i.e
On Sun, Oct 04, 2009 at 08:54:56PM -0400, Alvaro Herrera wrote:
> David E. Wheeler wrote:
> > On Oct 4, 2009, at 1:57 PM, David Fetter wrote:
> >
> > >It's less about like or dislike and more about facing up to the
> > >reality that we've got a major legacy foot-gun left over from the
> > >experim
David E. Wheeler wrote:
> On Oct 4, 2009, at 1:57 PM, David Fetter wrote:
>
> >It's less about like or dislike and more about facing up to the
> >reality that we've got a major legacy foot-gun left over from the
> >experimentation of the Berkeley days.
>
> I think you're going to need to be a bit
I see that the docs were recently changed from discouraging hash
indexes both because they were no known uses in which they were
meaningfully better than btree, and because they aren't recoverable;
to now just discouraging them because they are not recoverable. Does
that mean there are now uses in
On Sun, Oct 4, 2009 at 6:42 PM, David Fetter wrote:
>> I agree that rules, except for SELECT rules, don't seem to be very
>> useful. Perhaps others have found them so, but I have found
>> triggers to be a better fit for everything that I ever want to do.
>> Every time I think, hmm, maybe I could
On Oct 4, 2009, at 1:57 PM, David Fetter wrote:
It's less about like or dislike and more about facing up to the
reality that we've got a major legacy foot-gun left over from the
experimentation of the Berkeley days.
I think you're going to need to be a bit more concrete than that. In
what wa
Peter Eisentraut wrote:
> OK, but what you can do is point both variants to the same C function
> and check with PG_NARGS() with how many arguments you were called. That
> would save some of the indirections.
The regressiontest 'opr_sanity' failed if do so. Should we remove this
check only for
On Sun, October 4, 2009 1:48 pm, Pavel Stehule wrote:
> 2009/10/4 David Fetter :
>> Folks,
>>
>> At the moment, user-accessible RULEs have, as far as I know, just two
>> sane uses:
>>
>> * Writing to VIEWs
>> * Routing writes to partitions
>
> somebody use it as instead triggers. And I am sure, so
* David Fetter (da...@fetter.org) wrote:
> On Sun, Oct 04, 2009 at 04:07:40PM -0400, Robert Haas wrote:
> > > The radical proposal was the RULE system. It's been tested now,
> > > and it's pretty much failed.
> >
> > You still haven't explained what actual benefit we'd get out of
> > doing this.
On Sun, Oct 04, 2009 at 04:07:40PM -0400, Robert Haas wrote:
> On Sun, Oct 4, 2009 at 3:34 PM, David Fetter wrote:
> >> What would be the benefit of this radical proposal?
> >
> > The radical proposal was the RULE system. It's been tested now,
> > and it's pretty much failed.
>
> You still haven
On Wed, Sep 30, 2009 at 10:40 PM, Itagaki Takahiro
wrote:
>
> Euler Taveira de Oliveira wrote:
>
>> > But there are some confusions in postgres; ReadBufferCount and
>> > BufferHitCount are used for "get" and "hit", but "heap_blks_read"
>> > and "heap_blks_hit" are used for "read" and "hit" in pg_
Hi!
On Fri, Sep 25, 2009 at 7:01 AM, Emmanuel Cecchet wrote:
> Here is the new version of the patch that applies to CVS HEAD as of this
> morning.
Cool features!
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 l
On Sun, Oct 04, 2009 at 01:25:31PM -0700, Josh Berkus wrote:
> David,
>
> > The radical proposal was the RULE system. It's been tested now,
> > and it's pretty much failed.
>
> I don't think you've demonstrated that. I know *you* don't like
> RULEs, but others do.
It's less about like or disli
David,
> The radical proposal was the RULE system. It's been tested now, and
> it's pretty much failed.
I don't think you've demonstrated that. I know *you* don't like RULEs,
but others do. I could propose that UUIDs are a bankrupt concept (which
I believe) and therefore we should drop the UUI
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_ALIGNED;
> +
> + /* Default table style to plain ASCII */
> + pset.popt.t
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
>>> - redo (rather ugly) temporary pg_stat_lock_waits in a form more li
2009/10/4 David Fetter :
> On Sun, Oct 04, 2009 at 08:48:15PM +0200, Pavel Stehule wrote:
>> 2009/10/4 David Fetter :
>> > Folks,
>> >
>> > At the moment, user-accessible RULEs have, as far as I know, just two
>> > sane uses:
>> >
>> > * Writing to VIEWs
>> > * Routing writes to partitions
>>
>> so
On Sun, Oct 4, 2009 at 3:34 PM, David Fetter wrote:
>> What would be the benefit of this radical proposal?
>
> The radical proposal was the RULE system. It's been tested now, and
> it's pretty much failed.
You still haven't explained what actual benefit we'd get out of doing this.
I agree that
On Sun, 2009-10-04 at 11:56 -0700, Josh Berkus wrote:
> Except ... I can imagine a multi-tenant setup where certain ROLEs only
> have permissions on some child relations, but not others. So we'd want
> to still enable a permissions check on a child when the child is called
> directly rather than t
On Sun, Oct 04, 2009 at 11:42:45AM -0700, Josh Berkus wrote:
> > There are already patches to deal with the first, at least for the
> > kinds of VIEWs where this can be deduced automatically, and people
> > are starting to take on the second.
>
> How would we deal with VIEWs which weren't simple e
Tom Lane wrote:
Yeah, rewrite rules are going to be a *serious* stumbling block to
this whole concept. Maybe we should just punt the project until we
have a clear idea of how to do that.
I've implemented rewrite rules for writeable CTEs, and at least now I
don't see any problems except one. I
On Sun, Oct 04, 2009 at 03:15:10PM -0400, Andrew Dunstan wrote:
>
>
> Dan Colish wrote:
> >When you speak of writing to a view, what do you mean exactly? Are we saying
> >refresh a view or update the parent tables of a view?
> >
> >
>
> He means INSERT, UPDATE and DELETE operations on the view.
On Sun, Oct 04, 2009 at 08:48:15PM +0200, Pavel Stehule wrote:
> 2009/10/4 David Fetter :
> > Folks,
> >
> > At the moment, user-accessible RULEs have, as far as I know, just two
> > sane uses:
> >
> > * Writing to VIEWs
> > * Routing writes to partitions
>
> somebody use it as instead triggers.
Dan Colish wrote:
When you speak of writing to a view, what do you mean exactly? Are we saying
refresh a view or update the parent tables of a view?
He means INSERT, UPDATE and DELETE operations on the view.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On Sun, Oct 04, 2009 at 11:42:45AM -0700, Josh Berkus wrote:
>
> > There are already patches to deal with the first, at least for the
> > kinds of VIEWs where this can be deduced automatically, and people are
> > starting to take on the second.
>
> How would we deal with VIEWs which weren't simpl
> There are already patches to deal with the first, at least for the
> kinds of VIEWs where this can be deduced automatically, and people are
> starting to take on the second.
How would we deal with VIEWs which weren't simple enough for automated
updating, then?
I don't think that removing a maj
> So let's get rid of that. Selecting (or in general, operating) on a
> table with children only checks the privileges on that table, not the
> children. Is there any use case where the current behavior is useful at
> all?
In theory, someone out there may be using privs to restrict access to
c
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 permissions.
--Josh
--
Sen
2009/10/4 David Fetter :
> Folks,
>
> At the moment, user-accessible RULEs have, as far as I know, just two
> sane uses:
>
> * Writing to VIEWs
> * Routing writes to partitions
somebody use it as instead triggers. And I am sure, so there are
people, who use it for writable views.
regards
Pavel St
Folks,
At the moment, user-accessible RULEs have, as far as I know, just two
sane uses:
* Writing to VIEWs
* Routing writes to partitions
And the second is pretty thin, given the performance issues for
numbers of partitions over 2.
What say we see about addressing those problems separately, and
On Fri, Oct 02, 2009 at 05:34:16PM -0700, Brad T. Sliger wrote:
> On Friday 02 October 2009 04:21:35 Roger Leigh wrote:
> > I have attached a patch which implements the feature as a pset
> > variable. This also slightly simplifies some of the patch since
> > the table style is passed to functions
On Fri, 2009-09-25 at 10:01 -0400, Emmanuel Cecchet wrote:
> Robert,
>
> Here is the new version of the patch that applies to CVS HEAD as of this
> morning.
I just started looking at this now. It seems to fail "make check", diffs
attached. I haven't looked into the cause of the failure yet.
Reg
On Oct 4, 2009, at 1:24 PM, David Fetter wrote:
On Sun, Oct 04, 2009 at 01:16:50PM -0400, Tom Lane wrote:
Marko Tiikkaja writes:
If I understood you correctly, this would imply that you wouldn't
be able to do for example:
INSERT INTO foo
WITH t AS ( DELETE FROM bar RETURNING * )
SELECT *
On Sun, Oct 04, 2009 at 01:16:50PM -0400, Tom Lane wrote:
> Marko Tiikkaja writes:
> > If I understood you correctly, this would imply that you wouldn't
> > be able to do for example:
>
> > INSERT INTO foo
> > WITH t AS ( DELETE FROM bar RETURNING * )
> > SELECT * FROM t;
>
> Um ... forget what
Marko Tiikkaja writes:
> If I understood you correctly, this would imply that you wouldn't be
> able to do for example:
> INSERT INTO foo
> WITH t AS ( DELETE FROM bar RETURNING * )
> SELECT * FROM t;
Um ... forget what I said --- not enough caffeine yet, apparently.
Yeah, rewrite rules are goi
On Oct 4, 2009, at 11:47 AM, Tom Lane wrote:
Robert Haas writes:
Well, I think a patch to implement writeable CTEs is probably going
to
have to handle this case - I don't think we can just ignore rewrite
rules when processing a CTE. But it does seem to be beyond the scope
of the current pa
Tom Lane wrote:
Any given executor run only
has to think about one type of DML command --- otherwise the executor
would be broken already, since it takes only one command-type argument.
If I understood you correctly, this would imply that you wouldn't be
able to do for example:
INSERT INTO foo
Robert Haas writes:
> Well, I think a patch to implement writeable CTEs is probably going to
> have to handle this case - I don't think we can just ignore rewrite
> rules when processing a CTE. But it does seem to be beyond the scope
> of the current patch.
I hadn't been paying too much attentio
Andrew Gierth writes:
> This doesn't seem to present any problems as far as the syntax goes,
> and the actual execution is just a small matter of coding, but I'm not
> seeing the best way to handle it in parse-analysis. All the existing
> infrastructure for ORDER BY seems to be dependent on target
Peter Eisentraut writes:
> I understand the annoyance, but I think we do need to have an organized
> way to do testing of non-ASCII data and in particular UTF8 data, because
> there are an increasing number of special code paths for those.
Well, if you want to keep the test, we should put in the
Recently, I encountered a situation where the docs on (or impl?)
INCLUDING INDEXES and INCLUDING CONSTRAINTS are not clearly defined
for primary keys. Should it be noted in the docs that in this case, we
are referring to the technical implementation of a primary key, i.e. a
unique index and a not n
Robert Haas wrote:
I'm not saying that we don't
want to provide the means to do this, but writeable CTEs alone aren't
meant to handle this.
Well, I think a patch to implement writeable CTEs is probably going to
have to handle this case - I don't think we can just ignore rewrite
rules when proce
On Sun, Oct 4, 2009 at 8:14 AM, Robert Haas wrote:
> Marko -
>
> I noticed something a little odd about the new append-plan handling.
>
> rhaas=# explain update parent set c = 1;
> QUERY PLAN
> ---
>
Marko -
I noticed something a little odd about the new append-plan handling.
rhaas=# explain update parent set c = 1;
QUERY PLAN
---
Update (cost=0.00..60.80 rows=4080 width=12)
-> Seq Scan on
On Fri, Oct 2, 2009 at 7:37 AM, Marko Tiikkaja
wrote:
> Robert Haas wrote:
>>
>> Now the point here is that I eventually want to be able to write
>> something like this:
>>
>> with foo as (insert into project (name) values ('Writeable CTEs')
>> returning id) select * from foo;
>>
>> ...but how doe
The spec defines array_agg(foo ORDER BY ...) which we don't implement
yet; obviously, we have no reason not to define this for any
aggregate, rather than just array_agg.
This doesn't seem to present any problems as far as the syntax goes,
and the actual execution is just a small matter of coding,
On Sat, 2009-10-03 at 13:40 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > OK, the reason I couldn't reproduce this for the life of me is that I
> > had PGCLIENTENCODING=UTF8 in the environment of the server(!). Once I
> > unset that, I could reproduce the problem. This could be made a bi
67 matches
Mail list logo
