On 10 September 2015 at 21:48, Robert Haas wrote:
> The open items list here:
>
> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
>
> Dean's latest round of RLS refactoring.
This refactoring patch doesn't fix any behavioural issues. It is all
about trying to make the code simpler and m
On 11 September 2015 at 13:05, Robert Haas wrote:
> Thanks for the updates. My thoughts:
>
> On RETURNING, it seems like we've got a fairly fundamental problem
> here. If I understand correctly, the intention of allowing policies
> to be filtered by command type is to allow blind updates and del
On 11 September 2015 at 15:20, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> I think blind updates are a pretty niche case, and I think that it
>> wasn't the intention to support them, but more of an unintentional
>> side effect of the implem
On 11 September 2015 at 15:49, Tom Lane wrote:
> Dean Rasheed writes:
>> Yeah, we had a similar discussion regarding UPDATE USING policies and
>> ON CONFLICT UPDATE clauses. I think the argument against filtering is
>> that the rows returned would then be misleading about
On 11 September 2015 at 17:56, Tom Lane wrote:
> Dean Rasheed writes:
>> On 11 September 2015 at 15:49, Tom Lane wrote:
>>> However, I don't see why UPDATE/DELETE with RETURNING couldn't be
>>> restricted according to *both* the UPDATE and SELECT policies,
On 9 January 2014 15:33, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 7, 2014 at 1:15 PM, Tom Lane wrote:
>>> The next question is if we should allow it with LATERAL. That would
>>> essentially be treating "subscriber" as having implicitly appeared at the
>>> start of the FROM list, whi
On 18 January 2014 03:07, Marko Tiikkaja 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
On 19 January 2014 11:43, Marko Tiikkaja wrote:
>
>
> On 1/19/14, 9:12 AM, Dean Rasheed wrote:
>>
>> On 18 January 2014 03:07, Marko Tiikkaja wrote:
>>>
>>> Here's the patch as promised. Thoughts?
>>>
>>
>> A couple of poin
On 19 January 2014 11:43, Marko Tiikkaja 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 think of any c
On 20 January 2014 13:47, Marko Tiikkaja 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 des
On 20 January 2014 21:24, Alvaro Herrera 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 via pgsql-hackers maili
On 21 January 2014 01:09, KaiGai Kohei wrote:
> (2014/01/13 22:53), Craig Ringer wrote:
>>
>> On 01/09/2014 11:19 PM, Tom Lane wrote:
>>>
>>> Dean Rasheed writes:
>>>>
>>>> My first thought was that it should just preprocess any security
On 21 January 2014 22:28, Alvaro Herrera 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 to do what this does
On 23 January 2014 06:13, KaiGai Kohei wrote:
> A minor comment is below:
>
> ! /*
> !* Make sure that the query is marked correctly if the added
> qual
> !* has sublinks.
> !*/
> ! if (!parsetree->hasSubLinks)
> ! parsetree->ha
On 22 January 2014 09:54, David Rowley 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,
which I took as sign
On 24 January 2014 09:04, Craig Ringer 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 mutual recursion)
On 27 January 2014 07:54, Kouhei Kaigai 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 stick direction
>
On 25 January 2014 02:21, Florian Pflug 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: ARRAY_AGG()
On 28 January 2014 20:16, Florian Pflug wrote:
> On Jan27, 2014, at 23:28 , Dean Rasheed wrote:
>> strict transfn vs non-strict inv_transfn
>>
>>
>> This case is explicitly forbidden, both in CREATE AGGREGATE and in the
>
On 29 January 2014 11:27, Simon Riggs wrote:
> On 29 January 2014 06:43, Tom Lane 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 performance problems, so trying
On 29 January 2014 11:34, Craig Ringer wrote:
> On 01/23/2014 06:06 PM, Dean Rasheed wrote:
>> On 21 January 2014 09:18, Dean Rasheed wrote:
>>> Yes, please review the patch from 09-Jan
>>> (http://www.postgresql.org/message-id/CAEZATCUiKxOg=voovja2s6g-sixzzxg18totgg
On 29 January 2014 06:43, Tom Lane wrote:
> Kouhei Kaigai 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. You would however have to think
On 30 January 2014 05:36, Craig Ringer wrote:
> On 01/29/2014 08:29 PM, Dean Rasheed wrote:
>> On 29 January 2014 11:34, Craig Ringer wrote:
>>> On 01/23/2014 06:06 PM, Dean Rasheed wrote:
>>>> On 21 January 2014 09:18, Dean Rasheed wrote:
>>>>
On 20 February 2014 01:48, Florian Pflug wrote:
> On Jan29, 2014, at 13:45 , Florian Pflug 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 then require them.
On 13 February 2014 04:12, Craig Ringer 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.
>
>> +psql
On 25 February 2014 12:33, Florian Pflug wrote:
> On Feb24, 2014, at 17:50 , Dean Rasheed wrote:
>> On 20 February 2014 01:48, Florian Pflug wrote:
>>> On Jan29, 2014, at 13:45 , Florian Pflug wrote:
>>>> In fact, I'm
>>>> currently leaning toward
On 3 March 2014 23:00, Florian Pflug 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
>> e
On 5 March 2014 14:35, Florian Pflug wrote:
> On Mar4, 2014, at 21:09 , Dean Rasheed wrote:
>> On 3 March 2014 23:00, Florian Pflug wrote:
>>>> * In show_windowagg_info(), this calculation looks suspicious to me:
>>>>
>>>> double tperrow = wi
On 10 March 2014 03:36, Craig Ringer 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 now, but in the m
On 13 August 2013 00:01, Peter Eisentraut wrote:
> On Wed, 2013-08-07 at 21:19 -0400, Peter Eisentraut wrote:
>> To make the view updatable, provide an unconditional ON DELETE DO
>> INSTEAD rule or an INSTEAD OF DELETE trigger.
>>
>> I think it's a bit strange to claim that adding a DELETE rule/tr
On 14 May 2013 16:35, Peter Eisentraut wrote:
> Sometimes, the psql startup hangs when it cannot resolve or connect to a
> host. Intuitively, I would like to press Ctrl+C and correct the
> connection string or investigate. But that doesn't work because Ctrl+C
> is already bound to the query canc
On 20 September 2013 11:29, Samrat Revagade wrote:
>>
>>
>> > Okay, are you adding this to the september commitfest?
>> >
>>
>> OK, I've done that. I think that it's too late for 9.3.
>>
>
>
> +1 for idea.
>
> I have tested patch and got surprising results with Cent-OS
> Patch is working fine for
On 17 October 2013 03:29, Peter Eisentraut wrote:
> On Mon, 2013-07-08 at 16:04 +0000, Dean Rasheed wrote:
>> There was concern that pg_relation_is_updatable() would end up opening
>> every relation in the database, hammering performance. I now realise
>> that these tab-co
On 18 October 2013 15:43, Robert Haas wrote:
>
> Committed.
>
Excellent. Thank you!
And thank you Marko for your thorough review.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On 18 October 2013 16:41, Robert Haas wrote:
> On Fri, Oct 18, 2013 at 1:34 AM, Dean Rasheed
> wrote:
>>> Personally, I think this is too fancy anyway. I'd just complete all
>>> views and foreign tables and be done with it. We don't inspect
>>> perm
On 23 October 2013 02:18, Andres Freund wrote:
> Hi,
>
> Using the same debugging hack^Wpatch (0001) as in the matview patch
> (0002) an hour or so ago I noticed that INSERT INTO view WITH CHECK
> doesn't lock the underlying relations properly.
>
> I've attached a sort-of-working (0003) hack but I
On 23 October 2013 21:08, Andres Freund wrote:
> On 2013-10-23 20:51:27 +0100, Dean Rasheed wrote:
>> On 23 October 2013 02:18, Andres Freund wrote:
>> > Hi,
>> >
>> > Using the same debugging hack^Wpatch (0001) as in the matview patch
>> > (0002)
On 24 October 2013 18:28, Andres Freund wrote:
> On 2013-10-23 21:20:58 +0100, Dean Rasheed wrote:
>> On 23 October 2013 21:08, Andres Freund wrote:
>> > On 2013-10-23 20:51:27 +0100, Dean Rasheed wrote:
>> >> Hmm, my first thought is that rewrite
On 6 November 2013 09:23, Craig Ringer wrote:
> On 11/06/2013 05:02 PM, Dean Rasheed wrote:
>
>> The basic idea is to have rewriteTargetView() collect up any quals
>> from SB views in a new list on the target RTE, instead of adding them
>> to the main query's predica
On 6 November 2013 19:12, Kohei KaiGai wrote:
> 2013/11/6 Craig Ringer :
>> On 11/05/2013 09:36 PM, Robert Haas wrote:
>>> I haven't studied this patch in detail, but I see why there's some
>>> unhappiness about that code: it's an RLS-specific kluge. Just
>>> shooting from the hip here, maybe we
On 11 September 2015 at 15:51, Joe Conway wrote:
> On 09/11/2015 04:33 AM, Stephen Frost wrote:
>> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>>> I will happily work up a rebased version of the patch, but only if I
>>> get a serious commitment from a commit
On 13 September 2015 at 20:59, Stephen Frost wrote:
> I've been through this and definitely like it more than what we had
> previously, as I had mentioned previously. I've also added the
> RETURNING handling, per the discussion between you, Robert, Tom, and
> Kevin.
>
> Would be great to get your
On 13 September 2015 at 22:54, Stephen Frost wrote:
> Not in front of my laptop and will review it when I get back in more detail,
> but the original approach that I tried was changing
> get_policies_for_relation to try and build everything necessary, which
> didn't work as we need to OR the vario
On 14 September 2015 at 14:47, Stephen Frost wrote:
> Attached is a git format-patch built series which includes both commits,
> now broken out, for review.
>
That looks OK to me.
A minor point -- this comment isn't quite right:
/*
* For the target relation, when there is a returning l
On 15 September 2015 at 15:22, Stephen Frost wrote:
> Updated patch attached for review.
>
> Unless there are other concerns or issues raised, I'll push this later
> today.
>
Looks good to me.
Thanks for doing all this.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On 16 September 2015 at 14:49, Merlin Moncure wrote:
>> AFAICT, this kind of slowdown only happens in cases like this where a
>> very large number of digits are being returned.
>
> Can you clarify "very large"?
>
I haven't done much performance testing because I've been mainly
focussed on accurac
On 16 September 2015 at 16:14, Dean Rasheed wrote:
> On 16 September 2015 at 14:49, Merlin Moncure wrote:
>>> AFAICT, this kind of slowdown only happens in cases like this where a
>>> very large number of digits are being returned.
>>
>> Can you clarify "v
Hi,
By chance, while testing the nearby numeric log/exp/pow patch, I came
across the following case which generates an initially puzzling
looking error on HEAD -- (5.6-1e-500) ^ (3.2-1e-200). This computation
actually works OK with that other patch, but only by blind luck. It
turns out that the un
On 21 September 2015 at 16:09, Tom Lane wrote:
> I wrote:
>> Dean Rasheed writes:
>>> The problem then arises in the final carry propagation pass. During
>>> this phase of the computation, the carry from one digit (which can be
>>> a shade under INT_MAX / NB
On 24 September 2015 at 21:25, Tom Lane wrote:
> I wrote:
>> - List *ri_WithCheckOptions;
>> - List *ri_WithCheckOptionExprs;
>> + List *ri_InsertedCheckClauses;
>> + List *ri_InsertedCheckClauseExprs;
>
>> The distinction between a "clause" and an "expr" is
On 28 September 2015 at 20:15, Stephen Frost wrote:
> I listed out the various alternatives but didn't end up getting any
> responses to it. I'm still of the opinion that the documentation is the
> main thing which needs improving here, but we can also change CREATE
> POLICY, et al, to require an
On 8 October 2015 at 05:45, Haribabu Kommi wrote:
> On Thu, Oct 8, 2015 at 2:54 PM, Stephen Frost wrote:
>> It's quite late here, but I'll take a look at this in more depth
>> tomorrow.
>>
>> Based on what the Assert's testing, I took an educated guess and tried
>> running without the UNION ALL,
On 8 October 2015 at 15:05, Dean Rasheed wrote:
> Attached is a simple patch that appears to work, but it needs more
> testing (and some regression tests).
>
Here's an updated patch with an extra regression test case that
triggers the issue.
I've also updated the f
Currently PostgreSQL only has trigonometric functions that work in
radians. I think it would be quite useful to have an equivalent set of
functions that worked in degrees. In other environments these are
commonly spelled sind(), cosd(), etc.
Partly, this would be a matter of convenience. It's quit
On 25 October 2015 at 09:16, Emre Hasegeli wrote:
>> Currently PostgreSQL only has trigonometric functions that work in
>> radians. I think it would be quite useful to have an equivalent set of
>> functions that worked in degrees. In other environments these are
>> commonly spelled sind(), cosd(),
On 26 October 2015 at 14:18, Tom Lane wrote:
>> Having degree-based functions would make it trivial to implement
>> user-defined gradian-based functions, just by multiplying or dividing
>> by 0.9, and they would return exact results in the smaller number of
>> cases where gradian results are exact
On 26 October 2015 at 18:58, Tom Lane wrote:
> Dean Rasheed writes:
>> On 26 October 2015 at 14:18, Tom Lane wrote:
>>> ... but having said that, your argument here is faulty, because 0.9
>>> in itself is not exactly representable in binary. You'd be relying
On 26 October 2015 at 19:45, Peter Eisentraut wrote:
> On 10/24/15 5:24 AM, Dean Rasheed wrote:
>> Additionally, functions that worked natively in degrees would be able
>> to return exact answers in special cases like cosd(90) = 0, whereas
>> cos(radians(90)) is not exactly
On 26 October 2015 at 20:19, Tom Lane wrote:
> Dean Rasheed writes:
>> I'm thinking something along the lines of:
>
>> 1. Reduce the range of the input (say to 0..90 degrees).
>> 2. Handle special cases (0, 30 and 90 for sind()).
>> 3. Otherwise convert to ra
On 26 October 2015 at 22:51, Tom Lane wrote:
> Dean Rasheed writes:
>> Personally I'd rather have sind(30) be exactly 0.5, even if
>> sind(29.999...) or sind(30.000...1) ended up the wrong side of it.
>
> TBH, sir, if you think that you are too dangerous to be a
On 27 October 2015 at 08:24, Dean Rasheed wrote:
> I think it's still feasible to have sind(30) = 0.5 exactly and keep
> monotonicity
>
Here's a patch along those lines. It turned out to be fairly
straightforward. It's still basically a thin wrapper on top of the
mat
On 28 October 2015 at 16:50, Marko Tiikkaja wrote:
> Hi,
>
> Here's a patch for the aggregate function outlined by Corey Huinker in
> CADkLM=foA_oC_Ri23F9PbfLnfwXFbC3Lt8bBzRu3=cb77g9...@mail.gmail.com .
+1. I've wanted something like this a few times. Of the names
suggested so far, I think I pref
On 2 November 2015 at 09:10, Simon Riggs wrote:
> I think we should avoid using ONLY or VALUE within the names since those
> already have other meanings in Postgres.
>
We already have window functions called first_value, last_value and
nth_value, so I think use of "value" in the name is OK (and
c
On 2 November 2015 at 10:59, Marko Tiikkaja wrote:
> On 11/2/15 9:32 AM, Dean Rasheed wrote:
>>
>> On 28 October 2015 at 16:50, Marko Tiikkaja wrote:
>>>
>>> Here's a patch for the aggregate function outlined by Corey Huinker in
>>> C
On 11 November 2015 at 06:04, Michael Paquier wrote:
>>> I also modified some of the CHECKFLOATVAL() checks which didn't look
>>> right to me, unless there's some odd platform-specific behaviour that
>>> I'm not aware of, functions like sin and asin should never return
>>> infinity.
>
> - CH
On 12 November 2015 at 21:01, Tom Lane wrote:
> Dean Rasheed writes:
>> These results are based on the attached, updated patch which includes
>> a few minor improvements.
>
> I started to look at this patch, and was immediately bemused by the
> comme
On 13 November 2015 at 18:36, Tom Lane wrote:
> Next question: in the additional range-reduction step you added to ln_var,
> why stop there, ie, what's the rationale for this magic number:
>
> if (Abs((x.weight + 1) * DEC_DIGITS) > 10)
>
> Seems like we arguably should do this whenever the
On 13 November 2015 at 21:00, Tom Lane wrote:
> BTW, something I find confusing and error-prone is that this patch keeps
> on using the term "weight" to refer to numbers expressed in decimal digits
> (ie, the approximate log10 of something). Basically everywhere in the
> existing code, "weights"
On 13 November 2015 at 23:10, Tom Lane wrote:
> One more thing: the approach you used in power_var() of doing a whole
> separate exp * ln(base) calculation to approximate the result weight
> seems mighty expensive, even if it is done at minimal precision.
> Couldn't we get a good-enough approximat
On 14 November 2015 at 00:16, Dean Rasheed wrote:
> I can't see a way to make that work reliably. It would need to be
> 10^estimate_ln_weight(base) and the problem is that both exp and
> ln_weight could be too big to fit in double variables, and become
> HUGE_VAL, losing all prec
On 13 November 2015 at 21:34, Dean Rasheed wrote:
> On 13 November 2015 at 18:36, Tom Lane wrote:
>> Next question: in the additional range-reduction step you added to ln_var,
>> why stop there, ie, what's the rationale for this magic number:
>>
>> if
On 14 November 2015 at 16:13, Tom Lane wrote:
>> We might well want to keep the power-10 argument reduction step, but
>> it would now be there purely on performance grounds so there's scope
>> for playing around with the threshold at which it kicks in.
>
> My inclination is to get rid of it. I th
On 14 November 2015 at 20:05, Tom Lane wrote:
> I committed this with that change and some other
> mostly-cosmetic revisions.
Thanks.
> Notable non-cosmetic changes:
>
> * I forced all the computed rscales to be at least 0, via code like
> local_rscale = Max(local_rscale, NUMERIC_MIN_D
On 23 January 2012 20:14, Pavel Stehule wrote:
> Hello
>
> 2012/1/23 Robert Haas :
>> On Tue, Jan 3, 2012 at 2:49 PM, Pavel Stehule
>> wrote:
>>> jup, we can continue in enhancing step by step.
>>>
>>> I change a patch and now ALTER TABLE, ALTER INDEX, ALTER SEQUENCE and
>>> ALTER VIEW has IF EX
Given a freshly created table (not vacuumed), and a query that uses an
index-only scan, for example:
CREATE TABLE foo(a int PRIMARY KEY);
INSERT INTO foo SELECT * FROM generate_series(1,100);
ANALYSE foo;
EXPLAIN ANALYSE SELECT count(*) FROM foo WHERE a <= 1;
On 31 January 2012 17:35, Robert Haas wrote:
> On Sun, Jan 29, 2012 at 2:47 AM, Dean Rasheed
> wrote:
>> Given a freshly created table (not vacuumed), and a query that uses an
>> index-only scan, for example:
>>
>> CREATE TABLE foo(a int PRIMARY KEY);
&g
On 31 January 2012 19:49, Robert Haas wrote:
> On Tue, Jan 31, 2012 at 2:15 PM, Dean Rasheed
> wrote:
>> In the case when we're asked to clear a bit, it would first try to pin
>> the relevant page, which would go through vm_readbuf() with extend set
>> to true.
On 31 January 2012 23:04, Tom Lane wrote:
> Dean Rasheed writes:
>> The thing I'm unsure about is whether sending sinval
>> messages when the visibility map is extended is a good idea.
>
> Seems perfectly reasonable to me. They'd occur so seldom as to be
> more
On 2 February 2012 01:40, Robert Haas wrote:
> On Wed, Feb 1, 2012 at 7:44 PM, Robert Haas wrote:
>> So, I guess the trade-off here is that, since sinval messages aren't
>> processed immediately, we often won't notice the VM extension until
>> the next statement starts, whereas with the current i
Hi,
I just spotted that tab completion of double quoted identifiers seems
to be broken in 9.2devel. For example things like this which worked in
9.1 no longer work:
UPDATE "foo bar"
It looks like the problem is in get_previous_words() here:
if (buf[start] == '"')
On 16 May 2013 22:16, Tom Lane wrote:
>> Specifically, for foreign tables
>> information_schema.tables.is_insertable_into and
>> information_schema.columns.is_updatable always say 'NO' even if the
>> foreign table is writable. Fixing that would require new C functions
>> along the same lines as pg
Testing 9.3beta, it seems that array_remove() may return an empty 1-d
array whose upper bound is lower than its lower bound. I know that we
discussed allowing this kind of array, but I don't think that
discussion reached any conclusion, other than to agree that the
current empty 0-d array behaviour
On 31 May 2013 08:34, Brendan Jurd wrote:
> On 31 May 2013 02:52, Dean Rasheed wrote:
>> Testing 9.3beta, it seems that array_remove() may return an empty 1-d
>> array whose upper bound is lower than its lower bound. I know that we
>> discussed allowing this kind of array, b
On 4 June 2013 23:35, Michael Paquier wrote:
>
>
>
> On Wed, Jun 5, 2013 at 12:59 AM, Peter Eisentraut wrote:
>>
>> I was looking for a way in which the average psql user could learn
>> whether a view is updatable. I was expecting something in \d, \d+, \dv,
>> \dv+, or a NOTICE from CREATE VIEW.
On 5 June 2013 08:59, Dean Rasheed wrote:
> I'm still not happy with pg_view_is_updatable() et al. and the
> information_schema views. I accept that the information_schema views
> have to be the way they are because that's what's defined in the
> standard, but as
On 6 June 2013 08:09, Dean Rasheed wrote:
> On 5 June 2013 08:59, Dean Rasheed wrote:
>> I'm still not happy with pg_view_is_updatable() et al. and the
>> information_schema views. I accept that the information_schema views
>> have to be the way they are because th
On 11 June 2013 01:03, Michael Paquier wrote:
> Sorry for my late reply.
>
> On Sun, Jun 9, 2013 at 6:45 PM, Dean Rasheed
> wrote:
>>
>> I called it updatable rather than "writable" or "read-only" because it
>> might perhaps be extended in the fu
On 11 June 2013 22:53, Tom Lane wrote:
> Dean Rasheed writes:
>> Here's a more complete patch along those lines. It defines the
>> following pair of functions to test for updatability from SQL:
>
>> FUNCTION pg_catalog.pg_rel
On 12 June 2013 04:50, David E. Wheeler wrote:
> On Jun 11, 2013, at 3:09 PM, Brendan Jurd wrote:
>
>> There have been attempts to add a cardinality function in the past, as
>> it is required by the SQL spec, but these attempts have stalled when
>> trying to decide how it should handle multidim a
On 12 June 2013 18:35, Tom Lane wrote:
> looking at this patch some more ...
>
> Dean Rasheed writes:
>> One place where I think we have diverged from the spec, however, is in
>> information_schema.columns.updatable. This should be returning 'YES'
>> if the
On 12 June 2013 23:01, Tom Lane wrote:
> Dean Rasheed writes:
>> [ pg_relation_is_updatable.patch ]
>
> I've committed this with some modifications as mentioned. There is
> still room to debate exactly what
> information_schema.columns.is_updatable means --- we can no
On 13 June 2013 01:11, Tom Lane wrote:
> Dean Rasheed writes:
>> The more I read the spec, the less sense it seems to make, and each
>> time I read it, I seem to reach a different conclusion.
>
>> On my latest reading, I've almost convinced myself that "updat
On 9 June 2013 11:14, Dean Rasheed wrote:
> Here's a rebased version of the patch implementing WITH CHECK OPTION
> for auto-updatable views.
>
> It now includes documentation, and a clearer description of the
> patch's limitations --- WITH CHECK OPTION is only supported
Hi,
Attached is a patch implementing a new aggregate function md5_agg() to
compute the aggregate MD5 sum across a number of rows. This is
something I've wished for a number of times. I think the primary use
case is to do a quick check that 2 tables, possibly on different
servers, contain the same
On 14 June 2013 14:14, Tom Lane wrote:
> Marko Kreen writes:
>> On Thu, Jun 13, 2013 at 12:35 PM, Dean Rasheed
>> wrote:
>>> Attached is a patch implementing a new aggregate function md5_agg() to
>>> compute the aggregate MD5 sum across a number of rows.
>
On 14 June 2013 15:19, Stephen Frost wrote:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> I'd rather go the other way, processing the records without having
>> to process them otherwise at all. Turning things into text must slow
>> things down, surely.
>
> That's certainly an interesting idea
On 14 June 2013 16:09, Hannu Krosing wrote:
> What skytools/pgq/londiste uses for comparing tables on master
> and slave is query like this
>
> select sum(hashtext(t.*::text)) from t;
>
> This is non-modulo sum and does not use md5 but relies on
> whatever the hashtext() du jour is :)
>
> So it i
On 13 June 2013 10:35, Dean Rasheed wrote:
> Hi,
>
> Attached is a patch implementing a new aggregate function md5_agg() to
> compute the aggregate MD5 sum across a number of rows. This is
> something I've wished for a number of times. I think the primary use
> case is to
On 15 June 2013 10:22, Dean Rasheed wrote:
> There seem to be 2 separate directions that this could go, which
> really meet different requirements:
>
> 1). Produce an unordered sum for SQL to compare 2 tables regardless of
> the order in which they are scanned. A possible approac
On 17 June 2013 06:33, David Fetter wrote:
>> Next revision of the patch, now with more stability. Thanks, Andrew!
>
> Rebased vs. git master.
>
Here's my review of the WITH ORDINALITY patch.
Overall I think that the patch is in good shape, and I think that this
will be a very useful new featur
101 - 200 of 616 matches
Mail list logo
