On 1 April 2015 at 18:37, Andres Freund and...@anarazel.de wrote:
On 2015-04-01 13:29:33 -0400, Tom Lane wrote:
As for partitioning, you could do this:
create table parent(...);
create table child(...) inherits(parent); -- repeat as needed
create view v as select * from parent;
attach
On 27 March 2015 at 23:26, Tom Lane t...@sss.pgh.pa.us wrote:
Michael Paquier michael.paqu...@gmail.com writes:
It sounds appealing to switch the default behavior to something that
is more IEEE-compliant, and not only for scale == 0. Now one can argue
as well that changing the default is risky
On 28 March 2015 at 05:16, Andrew Gierth and...@tao11.riddles.org.uk wrote:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I think the concern over backwards compatibility here is probably
Tom overblown; but if we're sufficiently worried about it, a possible
Tom compromise is to invent a
On 22 March 2015 at 06:11, Pavel Stehule pavel.steh...@gmail.com wrote:
Hi
here is updated patch with array_position, array_positions implementation.
It is based on committed code - so please, revert commit
13dbc7a824b3f905904cab51840d37f31a07a9ef and apply this patch
I checked this and
do you have any idea about name for this function? array_position is ok?
+1 on array_position. It's possible at some point we'll actually want
array_offset that does what it claims.
+1 for array_position.
-1 for keeping array_offset. I'm not convinced that there are
sufficient use cases for
On 18 March 2015 at 19:03, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Pushed after adding error checks there and fixing the docs to match.
Please verify.
There's an issue when the array's lower bound isn't 1:
select array_offset('[2:4]={1,2,3}'::int[], 1);
array_offset
--
On 17 March 2015 at 23:25, Peter Geoghegan p...@heroku.com wrote:
Possibly I'm missing something though.
I think that you may have. Did you read the commit message/docs of the
RLS commit 0004-*? You must consider the second point here, I believe:
The 3 places that RLS policies are enforced
On 5 March 2015 at 23:44, Peter Geoghegan p...@heroku.com wrote:
On Wed, Mar 4, 2015 at 5:18 PM, Peter Geoghegan p...@heroku.com wrote:
Attached patch series forms what I'm calling V3.0 of the INSERT ... ON
CONFLICT IGNORE/UPDATE feature. (Sorry about all the threads. I feel
this development
I took another look at this and came up with some alternate comment
rewording. I also added a couple of additional comments that should
hopefully clarify the code a bit.
Regards,
Dean
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
new file mode 100644
On 16 March 2015 at 15:11, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Actually, on second thought I revisited this and changed the
representation for opfamilies and opclasses: instead of putting the AM
name in objargs, we can put it as the first element of objname instead.
That way,
On 26 February 2015 at 09:50, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 26 February 2015 at 05:43, Stephen Frost sfr...@snowman.net wrote:
I wonder if there are some documentation updates which need to be done
for this also? I'm planning to look as I vauguely recall mentioning
On 26 February 2015 at 09:27, Dean Rasheed dean.a.rash...@gmail.com wrote:
I think this should probably be committed as 2 separate patches...
On closer inspection, the 2 parts are interrelated since the new
self-join test that tests the inheritance planner changes also
requires the rewriter
On 27 February 2015 at 03:10, Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote:
On 2015/02/26 11:38, Stephen Frost wrote:
I've pushed an update for this to master and 9.4 and improved the
comments and the commit message as discussed.
Would be great if you could test and let me know if you run
Thanks for looking at this.
On 28 February 2015 at 04:25, Stephen Frost sfr...@snowman.net wrote:
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
Attached is a patch that does that, allowing restriction clause quals
to be pushed down into subquery RTEs if they contain leaky functions
On 1 March 2015 at 18:23, Stephen Frost sfr...@snowman.net wrote:
Thanks. Do you want me to post an update, or are you going to hack on it?
Either works for me, though I'm happy to handle the modifications to
this if it means you have time to look at the other patches.. :)
OK, I'll continue
On 26 February 2015 at 05:41, Stephen Frost sfr...@snowman.net wrote:
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
Here's an updated patch with a new test for this bug. I've been
developing the fixes for these RLS issues as one big patch, but I
suppose it would be easy to split up
On 26 February 2015 at 05:43, Stephen Frost sfr...@snowman.net wrote:
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
Attached is a patch to make RLS checks run before attempting to
insert/update any data rather than afterwards.
Excellent, this I really like and it's a pretty
On 18 February 2015 at 16:22, Stephen Frost sfr...@snowman.net wrote:
Here's the patch against master. I'm still fiddling with the comment
wording and the commit message a bit, but barring objections these
patches are what I'm planning to move forward with.
Yes, that matches what I had in
On 9 February 2015 at 21:17, Stephen Frost sfr...@snowman.net wrote:
On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
I noticed that when updating security barrier views on foreign tables,
we fail to give FOR UPDATE to selection queries issued at ForeignScan.
I've looked into this a fair
On 30 January 2015 at 03:40, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Jan 29, 2015 at 9:04 PM, Stephen Frost sfr...@snowman.net wrote:
A policy grants the ability to SELECT, INSERT, UPDATE, or DELETE rows
which match the relevant policy
On 29 January 2015 at 04:00, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Jan 7, 2015 at 3:06 PM, Stephen Frost sfr...@snowman.net wrote:
If I'm following correctly, Peter's specifically talking about:
[ USING ( replaceable
On 27 January 2015 at 22:45, Stephen Frost sfr...@snowman.net wrote:
Here's the latest set with a few additional improvements (mostly
comments but also a couple missed #include's and eliminating unnecessary
whitespace changes). Unless there are issues with my testing tonight or
concerns
On 10 January 2015 at 15:12, Stephen Frost sfr...@snowman.net wrote:
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
Currently we're applying RLS CHECKs after the INSERT or UPDATE, like
WITH CHECK OPTIONs on views. The SQL spec says that WITH CHECK OPTIONs
on views have to be applied after
On 14 January 2015 at 08:43, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 12 January 2015 at 14:24, Stephen Frost sfr...@snowman.net wrote:
Interesting, thanks for the work! I had been suspicious that there was
an issue with the recursion handling.
So continuing to review the RLS code, I
On 14 January 2015 at 13:29, Robert Haas robertmh...@gmail.com wrote:
One thing they could still leak is the number of times they got
called, and thus possibly the number of unseen rows. Now if the
expressions get constant-folded away that won't be an issue, but a
clever user can probably
On 12 January 2015 at 14:24, Stephen Frost sfr...@snowman.net wrote:
Interesting, thanks for the work! I had been suspicious that there was
an issue with the recursion handling.
So continuing to review the RLS code, I spotted the following in
prepend_row_security_policies():
/*
* We
On 13 January 2015 at 13:50, Stephen Frost sfr...@snowman.net wrote:
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 12 January 2015 at 22:16, Stephen Frost sfr...@snowman.net wrote:
Alright, here's an updated patch which doesn't return any detail if no
values are visible or if only
On 12 January 2015 at 22:16, Stephen Frost sfr...@snowman.net wrote:
Alright, here's an updated patch which doesn't return any detail if no
values are visible or if only a partial key is visible.
Please take a look. I'm not thrilled with simply returning an empty
string and then checking
On 10 January 2015 at 21:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
OK, I'll take a look at it. I started reading the existing code that
expands RLS policies and spotted a couple of bugs that should be fixed
first:-
1). In prepend_row_security_policies(), defaultDeny should
On 12 January 2015 at 14:24, Stephen Frost sfr...@snowman.net wrote:
Looking at the regression tests a bit though, I notice that this removes
the lower-level LockRows.. There had been much discussion about that
last spring which I believe you were a part of..? I specifically recall
On 9 January 2015 at 20:26, Stephen Frost sfr...@snowman.net wrote:
Where this leaves me, at least, is feeling like we should always apply
the INSERT WITH CHECK policy, then if there is a conflict, check the
UPDATE USING policy and throw an error if the row isn't visible but
otherwise perform
On 10 January 2015 at 15:12, Stephen Frost sfr...@snowman.net wrote:
NOTE: If we do change RLS CHECKs to be executed prior to modifying any
data, that's potentially a change that could be made independently of
the UPSERT patch. We should also probably then stop referring to them
as WITH CHECK
On 9 January 2015 at 20:46, Stephen Frost sfr...@snowman.net wrote:
I'd suggest we further clarify
with:
The commandCREATE POLICY/command command defines a new policy for a
table. Note that row level security must also be enabled on the table
using
commandALTER TABLE/command in
On 9 January 2015 at 00:49, Stephen Frost sfr...@snowman.net wrote:
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
For column level privileges, you wouldn't expect to only get an error
about not having the relevant update permissions at runtime, when the
update path happens to be taken.
On 8 January 2015 at 18:57, Stephen Frost sfr...@snowman.net wrote:
What do you think of the attached rewording?
Rewording it this way is a great idea. Hopefully that will help address
the confusion which we've seen. The only comment I have offhand is:
should we should add a sentence to
On 9 January 2015 at 08:49, Peter Geoghegan p...@heroku.com wrote:
On Fri, Jan 9, 2015 at 12:19 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
I was trying to think up an example where you might actually have
different INSERT and UPDATE policies, and the best I can think of is
some sort
A while ago [1] I proposed an enhancement to the way qual pushdown
safety is decided in RLS / security barrier views. Currently we just
test for the presence of leaky functions in the qual, but it is
possible to do better than that, by further testing if the leaky
function is actually being passed
On 8 January 2015 at 08:30, Dean Rasheed dean.a.rash...@gmail.com wrote:
I have a wider concern about the wording on this page - both the
rewritten paragraph and elsewhere talk about policies in terms of
limiting access to or filtering out rows.
However, since policy expressions are OR'ed
On 6 January 2015 at 19:25, Stephen Frost sfr...@snowman.net wrote:
Robert, Amit,
* Robert Haas (robertmh...@gmail.com) wrote:
I don't think that's a typo, although it's not particularly
well-worded IMHO. I might rewrite the whole paragraph like this:
A policy limits the ability to SELECT,
On 6 January 2015 at 20:44, Peter Geoghegan p...@heroku.com wrote:
Another issue that I see is that there is only one resultRelation
between the INSERT and UPDATE. That means that without some additional
special measure, both UPDATE and INSERT WITH CHECK ( ... ) options
are applied regardless
On 27 November 2014 at 19:20, Tom Lane t...@sss.pgh.pa.us wrote:
The attached proposed patch adds bms_next_member() and replaces
bms_first_member() calls where it seemed to make sense. I've had a
hard time measuring much speed difference for this patch in isolation,
but in principle it should
On 29 October 2014 13:04, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Oct 29, 2014 at 8:16 AM, Stephen Frost sfr...@snowman.net wrote:
suggestions. If the user does not have table-level SELECT rights,
they'll see for the Failing row contains
On 30 September 2014 16:52, Stephen Frost sfr...@snowman.net wrote:
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 29 September 2014 16:46, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Well, I think that's an acceptable approach from the point
On 30 September 2014 20:17, Stephen Frost sfr...@snowman.net wrote:
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 30 September 2014 16:52, Stephen Frost sfr...@snowman.net wrote:
If the user only has column-level privileges on the table then I'm not
really sure how useful the detail
On 26 September 2014 15:48, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Sep 24, 2014 at 5:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM that the most appropriate solution here is to insist that all or none
of the members of an operator class
On 27 September 2014 14:33, Stephen Frost sfr...@snowman.net wrote:
Yeah, I take that back. If there is a composite key involved then you
can run into the same issue- you update one of the columns to a
conflicting value and get back the entire key, including columns you
shouldn't be allowed
On 20 September 2014 14:08, Michael Paquier michael.paqu...@gmail.com wrote:
On Sat, Sep 20, 2014 at 7:03 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Fortunately it looks pretty trivial though. The patch attached fixes
the above test cases.
Obviously this needs to be fixed in 9.4
On 20 September 2014 06:13, Andrew Gierth and...@tao11.riddles.org.uk wrote:
Adam == Brightwell, Adam adam.brightw...@crunchydatasolutions.com
writes:
Adam At any rate, this appears to be a previously existing issue
Adam with WITH CHECK OPTION. Thoughts?
It's definitely an existing
On 29 June 2014 20:42, Stephen Frost sfr...@snowman.net wrote:
To try and clarify what this distinction is-
Dean's approach with GRANT allows specifying the policy to be
used when a given role queries a given table. Through this mechanism,
one role might have access to many different tables,
On 1 July 2014 17:42, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
An annoying complication, however, is how this interacts with column
privileges. Right now GRANT SELECT(col1) ON t1 TO role1 gives role1
access to every
On 26 June 2014 18:04, Robert Haas robertmh...@gmail.com wrote:
ALTER TABLE t1 SET POLICY p1 ON SELECT TO t1_p1_sel_quals;
GRANT SELECT ON TABLE t1 TO role1 USING p1;
As I see it, the downside of this is that it gets a lot more complex.
We have to revise the ACL representation, which is
On 25 June 2014 01:49, Stephen Frost sfr...@snowman.net wrote:
Dean, all,
Changing the subject of this thread (though keeping it threaded) as
we've really moved on to a much broader discussion.
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 24 June 2014 17:27, Stephen Frost sfr
On 25 June 2014 16:44, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 24, 2014 at 8:49 PM, Stephen Frost sfr...@snowman.net wrote:
Let's try to outline what this would look like then.
Taking your approach, we'd have:
CREATE POLICY p1;
CREATE POLICY p2;
ALTER TABLE t1 SET POLICY p1
On 24 June 2014 17:27, Stephen Frost sfr...@snowman.net wrote:
Single policy vs Multiple, Overlapping policies vs Multiple, Non-overlapping
policies
What I was describing upthread was multiple non-overlapping policies.
I disagree that this will be more complicated to use. It's a strict
Thinking about the examples upthread, a separate issue occurs to me
--- when defining a RLS qual, I think that there has to be a syntax to
specify an alias for the main table, so that correlated subqueries can
refer to it. I'm not sure if that's been mentioned in any of the
discussions so far, but
On 17 June 2014 20:19, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Yeah, I was thinking something like this could work, but I would go
further. Suppose you had separate GRANTable privileges for direct
access
On 13 June 2014 01:13, Stephen Frost sfr...@snowman.net wrote:
Greg, all,
I will reply to the emails in detail when I get a chance but am out of town
at a funeral, so it'll likely be delayed. I did want to echo my agreement
for the most part with Greg and in particular...
On Thursday, June
correct).
===
Allow the updating of views where only some columns are
auto-updateable (Dean Rasheed)
Previously the presence of a non-auto-updateable column prevented all
columns from being auto-updated. Deletes are now supported on suitable
views even if no auto-updateable columns are present
On 14 May 2014 15:07, Bruce Momjian br...@momjian.us wrote:
On Wed, May 14, 2014 at 08:33:15AM +0100, Dean Rasheed wrote:
On 4 May 2014 13:46, Bruce Momjian br...@momjian.us wrote:
I have completed the initial version of the 9.4 release notes. You can
view them here:
http
On 13 April 2014 05:23, Stephen Frost sfr...@snowman.net wrote:
Alright, I've committed this with an updated note regarding the locking,
and a few additional regression tests
That's awesome. Thank you very much.
Regards,
Dean
--
Sent via pgsql-hackers mailing list
On 11 April 2014 04:04, Stephen Frost sfr...@snowman.net wrote:
Dean, Craig, all,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
This is reflected in the change to the regression test output where,
in one of the tests, the ctids for the table to update are no longer
coming from the same
On 10 April 2014 22:52, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
I was imagining that firsttrans would only be passed the first value
to be aggregated, not any previous state, and that it would be illegal
to specify both an initcond and a firsttrans
On 10 April 2014 15:18, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
On 10 April 2014 01:13, Florian Pflug f...@phlo.org wrote:
However, I still believe the best approach at this point is to just work
on making int4_avg_accum faster. I still see no principal
On 10 April 2014 19:04, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
On 10 April 2014 15:18, Tom Lane t...@sss.pgh.pa.us wrote:
This idea of a separate firsttrans function is interesting but perhaps
orthogonal to the current patch. Also, I don't quite
On 10 April 2014 19:54, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
On 10 April 2014 19:04, Tom Lane t...@sss.pgh.pa.us wrote:
What about names for the invertible-aggregate infrastructure?
I'm tempted to prefix inv to all the existing names
On 8 April 2014 21:48, Florian Pflug f...@phlo.org wrote:
On Apr7, 2014, at 17:41 , Dean Rasheed dean.a.rash...@gmail.com wrote:
I've just finished reading through all the other patches, and they all
look OK to me. It's mostly straightforward stuff, so despite the size
it's hopefully all
On 9 April 2014 22:55, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
I was (and still am) not in favour of duplicating the whole quadruple of
(state, initialvalue, transferfunction, finalfunction) because it seems
excessive. In fact, I believed that doing this would
On 10 April 2014 01:13, Florian Pflug f...@phlo.org wrote:
Also, the *only* reason that SUM(int2|int4) cannot use int8 as it's
transition type is that it needs to return NULL, not 0, if zero rows
were aggregates. It might seems that it could just use int8 as state
with initial value NULL, but
On 7 April 2014 14:09, Florian Pflug f...@phlo.org wrote:
On Apr5, 2014, at 09:55 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 5 April 2014 08:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
[snip] releasing it in this state feels a little half-baked
to me.
I regret writing
On 4 April 2014 11:56, Florian Pflug f...@phlo.org wrote:
On 04.04.2014, at 09:40, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'm not sure how much additional work is required to sort this out,
but to me it looks more realistic to target 9.5 than 9.4, so at this
point I tend to think
On 5 April 2014 08:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
[snip] releasing it in this state feels a little half-baked
to me.
I regret writing that almost as soon as I sent it. The last of those
queries is now over 10 times faster than HEAD, which is certainly
worthwhile. What bugs me
On 1 April 2014 20:58, Florian Pflug f...@phlo.org wrote:
On Apr1, 2014, at 10:08 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 31 March 2014 01:58, Florian Pflug f...@phlo.org wrote:
Attached are updated patches that include the EXPLAIN changes mentioned
above and updated docs
On 31 March 2014 01:58, Florian Pflug f...@phlo.org wrote:
Attached are updated patches that include the EXPLAIN changes mentioned
above and updated docs.
These patches need re-basing --- they no longer apply to HEAD.
Regards,
Dean
--
Sent via pgsql-hackers mailing list
On 27 March 2014 21:01, Florian Pflug f...@phlo.org wrote:
First, sorry guys for letting this slide - I was overwhelmed by other works,
and this kind of slipped my mind :-(
On Mar27, 2014, at 09:04 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 26 March 2014 19:43, David Rowley dgrowle
On 26 March 2014 19:43, David Rowley dgrowle...@gmail.com wrote:
On Thu, Mar 27, 2014 at 7:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
I've attached an updated invtrans_strictstrict_base patch which has the
feature removed.
What is the state of play
On 10 March 2014 03:36, Craig Ringer cr...@2ndquadrant.com wrote:
I've found an issue with updatable security barrier views. Locking is
being pushed down into the subquery. Locking is thus applied before
user-supplied quals are, so we potentially lock too many rows.
I'm looking into the code
On 5 March 2014 14:35, Florian Pflug f...@phlo.org wrote:
On Mar4, 2014, at 21:09 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 3 March 2014 23:00, Florian Pflug f...@phlo.org wrote:
* In show_windowagg_info(), this calculation looks suspicious to me:
double tperrow = winaggstate
On 3 March 2014 23:00, Florian Pflug f...@phlo.org wrote:
* In show_windowagg_info(), this calculation looks suspicious to me:
double tperrow = winaggstate-aggfwdtrans /
(inst-nloops * inst-ntuples);
If the node is executed multiple times, aggfwdtrans will be reset in
each
On 25 February 2014 12:33, Florian Pflug f...@phlo.org wrote:
On Feb24, 2014, at 17:50 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 20 February 2014 01:48, Florian Pflug f...@phlo.org wrote:
On Jan29, 2014, at 13:45 , Florian Pflug f...@phlo.org wrote:
In fact, I'm
currently leaning
On 20 February 2014 01:48, Florian Pflug f...@phlo.org wrote:
On Jan29, 2014, at 13:45 , Florian Pflug f...@phlo.org wrote:
In fact, I'm
currently leaning towards just forbidding non-strict forward transition
function with strict inverses, and adding non-NULL counters to the
aggregates that
On 13 February 2014 04:12, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/11/2014 08:19 PM, Yeb Havinga wrote:
I compared output of psql -ef of the minirim.sql script posted earlier
in http://www.postgresql.org/message-id/52f54927.1040...@gmail.com
between v4 and v7.
Not everything is ok.
On 30 January 2014 05:36, Craig Ringer cr...@2ndquadrant.com wrote:
On 01/29/2014 08:29 PM, Dean Rasheed wrote:
On 29 January 2014 11:34, Craig Ringer cr...@2ndquadrant.com wrote:
On 01/23/2014 06:06 PM, Dean Rasheed wrote:
On 21 January 2014 09:18, Dean Rasheed dean.a.rash...@gmail.com wrote
On 28 January 2014 20:16, Florian Pflug f...@phlo.org wrote:
On Jan27, 2014, at 23:28 , Dean Rasheed dean.a.rash...@gmail.com wrote:
strict transfn vs non-strict inv_transfn
This case is explicitly forbidden, both in CREATE AGGREGATE
On 29 January 2014 11:27, Simon Riggs si...@2ndquadrant.com wrote:
On 29 January 2014 06:43, Tom Lane t...@sss.pgh.pa.us wrote:
Actually though, isn't this issue mostly about inheritance of a query
*target* table?
Exactly. IMHO updateable views on inheritance sets will have multiple
other
On 29 January 2014 11:34, Craig Ringer cr...@2ndquadrant.com wrote:
On 01/23/2014 06:06 PM, Dean Rasheed wrote:
On 21 January 2014 09:18, Dean Rasheed dean.a.rash...@gmail.com wrote:
Yes, please review the patch from 09-Jan
(http://www.postgresql.org/message-id/CAEZATCUiKxOg=voovja2s6g
On 29 January 2014 06:43, Tom Lane t...@sss.pgh.pa.us wrote:
Kouhei Kaigai kai...@ak.jp.nec.com writes:
Let me ask an elemental question. What is the reason why inheritance
expansion logic should be located on the planner stage, not on the tail
of rewriter?
I think it's mostly historical.
On 27 January 2014 07:54, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Hello,
I checked the latest updatable security barrier view patch.
Even though I couldn't find a major design problem in this revision,
here are two minor comments below.
I think, it needs to be reviewed by committer to
On 25 January 2014 02:21, Florian Pflug f...@phlo.org wrote:
I've now split this up into
invtrans_base: Basic machinery plus tests with SQL-language aggregates
invtrans_arith: COUNT(),SUM(),AVG(),STDDEV() and the like
invtrans_minmax: MIN(),MAX(),BOOL_AND(),BOOL_OR()
invtrans_collecting:
On 24 January 2014 09:04, Craig Ringer cr...@2ndquadrant.com wrote:
Hi all
I've hit an interesting wrinkle and am interested in opinions. By
integrating updatable security barrier view support with row-security,
it has become a lot harder to detect and prevent infinite recursion
(including
On 23 January 2014 06:13, KaiGai Kohei kai...@ak.jp.nec.com wrote:
A minor comment is below:
! /*
!* Make sure that the query is marked correctly if the added
qual
!* has sublinks.
!*/
! if (!parsetree-hasSubLinks)
!
On 22 January 2014 09:54, David Rowley dgrowle...@gmail.com wrote:
I've performed some more benchmarks on this patch tonight. The results and
full recreation scripts are attached along with the patch it was tested
against.
I noticed that the rate of changes to this patch has dropped off,
On 21 January 2014 01:09, KaiGai Kohei kai...@ak.jp.nec.com wrote:
(2014/01/13 22:53), Craig Ringer wrote:
On 01/09/2014 11:19 PM, Tom Lane wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
My first thought was that it should just preprocess any security
barrier quals
On 21 January 2014 22:28, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
I have been mulling over this patch, and I can't seem to come to terms
with it. I first started making it look nicer here and there, thinking
it was all mostly okay, but eventually arrived at the idea that it seems
wrong
On 19 January 2014 11:43, Marko Tiikkaja ma...@joh.to wrote:
New version attached, without the doc change.
This looks good to me.
- applies cleanly.
- compiles with no warnings.
- passes a sensible set of new regression tests.
- implements the agreed behaviour, per SQL spec.
- I can't
On 20 January 2014 13:47, Marko Tiikkaja ma...@joh.to wrote:
On 1/20/14 2:29 PM, Dean Rasheed wrote:
I think this is ready for committer
Thanks!
... although I would also like to see
the doc changes to make the table of array function descriptions a bit
more explicit about corner cases
On 20 January 2014 21:24, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
* fault tolerant DROP IF EXISTS
I gave a look and it looks good for application. This wasn't
superceded by a future version, correct?
No, this hasn't been superceded. +1 for applying it.
Regards,
Dean
--
Sent
On 18 January 2014 03:07, Marko Tiikkaja ma...@joh.to wrote:
On 1/12/14, 5:53 AM, I wrote:
On 1/9/14, 2:57 PM, Dean Rasheed wrote:
How it should behave for multi-dimensional arrays is less clear, but
I'd argue that it should return the total number of elements, i.e.
cardinality('{{1,2},{3,4
On 19 January 2014 11:43, Marko Tiikkaja ma...@joh.to wrote:
On 1/19/14, 9:12 AM, Dean Rasheed wrote:
On 18 January 2014 03:07, Marko Tiikkaja ma...@joh.to wrote:
Here's the patch as promised. Thoughts?
A couple of points:
The answer for empty (zero dimensional) arrays is wrong
On 9 January 2014 15:33, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 7, 2014 at 1:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The next question is if we should allow it with LATERAL. That would
essentially be treating subscriber as having implicitly
On 12 January 2014 10:12, Craig Ringer cr...@2ndquadrant.com wrote:
On 01/09/2014 06:48 PM, Dean Rasheed wrote:
On 8 January 2014 10:19, Dean Rasheed dean.a.rash...@gmail.com wrote:
The assertion failure with inheritance and sublinks is a separate
issue --- adjust_appendrel_attrs
201 - 300 of 605 matches
Mail list logo
