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
substantive reject at ecpg.addons:407 (FetchStmtMOVEfetch_args).
On Sat, 2009-10-03 at 13:40 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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 Fri, Oct 2, 2009 at 7:37 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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;
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 Sun, Oct 4, 2009 at 8:14 AM, Robert Haas robertmh...@gmail.com wrote:
Marko -
I noticed something a little odd about the new append-plan handling.
rhaas=# explain update parent set c = 1;
QUERY PLAN
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
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
Peter Eisentraut pete...@gmx.net 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
Andrew Gierth and...@tao11.riddles.org.uk 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
Robert Haas robertmh...@gmail.com 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
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
On Oct 4, 2009, at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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.
On Sun, Oct 04, 2009 at 01:16:50PM -0400, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
On Oct 4, 2009, at 1:24 PM, David Fetter da...@fetter.org wrote:
On Sun, Oct 04, 2009 at 01:16:50PM -0400, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
If I understood you correctly, this would imply that you wouldn't
be able to do for example:
INSERT INTO foo
WITH
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.
Regards,
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
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,
2009/10/4 David Fetter da...@fetter.org:
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.
On 10/3/09 8:09 AM, Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com 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.
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
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 major
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 enough
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
On Sun, Oct 04, 2009 at 08:48:15PM +0200, Pavel Stehule wrote:
2009/10/4 David Fetter da...@fetter.org:
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.
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.
cheers
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.
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 enough
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
On Sun, Oct 4, 2009 at 3:34 PM, David Fetter da...@fetter.org 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
2009/10/4 David Fetter da...@fetter.org:
On Sun, Oct 04, 2009 at 08:48:15PM +0200, Pavel Stehule wrote:
2009/10/4 David Fetter da...@fetter.org:
Folks,
At the moment, user-accessible RULEs have, as far as I know, just two
sane uses:
* Writing to VIEWs
* Routing writes to partitions
On Mon, Sep 28, 2009 at 12:14 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Sat, Aug 8, 2009 at 7:47 PM, Mark Kirkwood mar...@paradise.net.nz wrote:
Patch with max(wait time).
Still TODO
- amalgamate individual transaction lock waits
- redo (rather ugly) temporary
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 */
+
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 UUID
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 dislike and
Hi!
On Fri, Sep 25, 2009 at 7:01 AM, Emmanuel Cecchet m...@asterdata.com 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
On Wed, Sep 30, 2009 at 10:40 PM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Euler Taveira de Oliveira eu...@timbira.com 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
On Sun, Oct 04, 2009 at 04:07:40PM -0400, Robert Haas wrote:
On Sun, Oct 4, 2009 at 3:34 PM, David Fetter da...@fetter.org 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
* 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.
Removing
On Sun, October 4, 2009 1:48 pm, Pavel Stehule wrote:
2009/10/4 David Fetter da...@fetter.org:
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
Peter Eisentraut pete...@gmx.net 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
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
On Sun, Oct 4, 2009 at 6:42 PM, David Fetter da...@fetter.org 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 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
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 more
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
experimentation of
Khee Chin kheec...@gmail.com 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
On Sun, Oct 4, 2009 at 8:54 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Peter Eisentraut pete...@gmx.net 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
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 hearing of it,
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Peter Eisentraut pete...@gmx.net 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
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
Jeff Janes jeff.ja...@gmail.com 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
Hi,
On Sat, Oct 3, 2009 at 7:30 AM, shakahsha...@gmail.com
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
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 that hard to do?
I found
Joe Conway m...@joeconway.com 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
On Sun, Oct 4, 2009 at 10:01 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Joe Conway m...@joeconway.com 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
Tom Lane t...@sss.pgh.pa.us 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
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
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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.
Robert Haas robertmh...@gmail.com 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
On Sun, Oct 4, 2009 at 11:22 PM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com 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
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 robertmh...@gmail.com wrote:
?* Can I
65 matches
Mail list logo
