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 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 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 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 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 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 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 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 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 12 January 2014 10:12, Craig Ringer wrote:
> On 01/09/2014 06:48 PM, Dean Rasheed wrote:
>> On 8 January 2014 10:19, Dean Rasheed wrote:
>>> The assertion failure with inheritance and sublinks is a separate
>>> issue --- adjust_appendrel_attrs() is not expectin
On 10 January 2014 08:12, David Rowley wrote:
> On Fri, Jan 10, 2014 at 4:09 AM, Dean Rasheed
> wrote:
>>
>> Hi,
>>
>> Reading over this, I realised that there is a problem with NaN
>> handling --- once the state becomes NaN, it can never recover. So the
>
On 10 January 2014 00:36, Marko Tiikkaja wrote:
> On 1/10/14, 1:20 AM, Merlin Moncure wrote:
>>
>> I'm piling on: it's not clear at all to me why you've special cased
>> this to lower_bound=1. First of all, there are other reasons to check
>> length than iteration.
>
Yes, I agree. A length funct
On 9 January 2014 15:19, Tom Lane wrote:
> Dean Rasheed writes:
>> My first thought was that it should just preprocess any security
>> barrier quals in subquery_planner() in the same way as other quals are
>> preprocessed. But thinking about it further, those quals are dest
On 15 December 2013 01:57, Tom Lane wrote:
> Josh Berkus writes:
>> I think even the FLOAT case deserves some consideration. What's the
>> worst-case drift?
>
> Complete loss of all significant digits.
>
> The case I was considering earlier of single-row windows could be made
> safe (I think) if
On 19 December 2013 08:05, Pavel Stehule wrote:
>
>
>
> 2013/12/19 David Fetter
>>
>> On Wed, Dec 18, 2013 at 09:27:54PM +0100, Marko Tiikkaja wrote:
>> > Hi,
>> >
>> > Attached is a patch to add support for array_length(anyarray), which
>> > only works for one-dimensional arrays, returns 0 for e
On 24 December 2013 12:12, Craig Ringer wrote:
> On 12/24/2013 03:21 PM, Abbas Butt wrote:
>
>> Could you please explain a little bit more how would you solve the posed
>> problem using map_variable_attnos?
>
> It actually turns out to be even simpler, and easy to do in one pass,
> when using Repl
On 13 December 2013 15:07, Tom Lane wrote:
> Dean Rasheed writes:
>> I can't think of any practical uses for this kind of query, so I don't
>> think it's worth worrying too much about its results until/unless
>> someone comes up with a real use-case.
>
>
On 13 December 2013 01:14, Tom Lane wrote:
> The only thing I've come across that arguably doesn't work is SELECT
> DISTINCT:
>
> regression=# select distinct from pg_database;
> --
> (8 rows)
>
> The reason this says "8 rows" is that the produced plan is just a seqscan
> of pg_database returning
On 5 December 2013 10:06, Pavel Stehule wrote:
>> I think #1175 is close to being ready for commit. Pavel, will you
>> produce an updated patch based on our last discussion? I'll set this
>> patch to waiting on author.
>
>
> I expected so your version was a final. I have no problem to do other
> e
On 5 December 2013 01:33, Peter Eisentraut wrote:
> Can someone in this thread clarify the commit fest situation? I see two
> entries that appear to be the same:
>
> https://commitfest.postgresql.org/action/patch_view?id=1174
> https://commitfest.postgresql.org/action/patch_view?id=1175
>
> I thi
On 2 December 2013 04:55, Pavel Stehule wrote:
> Hello
>
> it looks well, thank you
>
> Regards
>
> Pavel
>
I've been thinking about this some more, and there's another case that
concerns me slightly. We're now making some of the DROP...IF EXISTS
commands tolerate non-existent types as well as no
On 3 December 2013 23:37, Tom Lane wrote:
> Thinking some more about bug #8648, it occurred to me that ruleutils.c
> isn't exactly prepared for the case either:
>
> regression=# create table nocols();
> CREATE TABLE
> regression=# create view vv1 as select exists (select * from nocols);
> CREATE V
On 2 December 2013 19:37, Alvaro Herrera wrote:
> Dean Rasheed escribió:
>
>> +/*
>> + * If a schema was explicitly specified, test if it exists. If it does not,
>> + * report the schema as missing rather than the child object.
>> + */
>> +static bool
>
On 1 December 2013 07:32, Pavel Stehule wrote:
>
>
>
> 2013/11/30 Peter Eisentraut
>>
>> trailing whitespace
>
>
> fixed,
>
Hi,
I've been looking at this and I think it's mostly in good shape, but I
spotted a few minor issues:
* There's a typo in the notice text in a couple of places --- "does
On 26 November 2013 19:54, Peter Eisentraut wrote:
> On 11/24/13, 2:28 PM, Pavel Stehule wrote:
>> Note: DROP TRIGGER ON tablename is PostgreSQL feature - no other
>> databases (without PostgreSQL forks) uses this syntax - so we don't need
>> thinking what is in (or what will be) in ANSI standard
On 21 November 2013 13:15, Craig Ringer wrote:
> Hi all
>
> I have updatable security barrier views working for INSERT and DELETE,
> so this might be a good chance to see whether the described approach is
> acceptable in reality, not just in theory.
>
> I've been surprised by how well it worked ou
On 20 November 2013 22:46, Andrew Gierth wrote:
>> "Tom" == Tom Lane writes:
>
> Tom> 1. Reinsert HEAD's prohibition against directly combining WITH
> Tom> ORDINALITY with a coldeflist (with a better error message and a
> Tom> HINT suggesting that you can get what you want via the TABLE
>
On 12 November 2013 16:00, Pavel Stehule wrote:
> Hello
>
> here is patch with fault tolerant drop trigger and drop rule support
>
> drop trigger [if exists] trgname on [if exists] tablename;
> drop rule [if exists] trgname on [if exists] tablename;
>
> Regards
>
> Pavel
>
Hi,
I have just starte
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 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 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 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 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 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 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 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 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 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 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 30 July 2013 11:09, hubert depesz lubaczewski wrote:
> On Tue, Jul 30, 2013 at 09:23:19AM +0100, Dean Rasheed wrote:
>> >> > > create table some_data (id int4 primary key, payload text);
>> >> > > create view first as select * from some_data where 0 = id
On 30 July 2013 01:24, Stephen Frost wrote:
> depesz,
>
> * hubert depesz lubaczewski (dep...@depesz.com) wrote:
>> On Mon, Jul 29, 2013 at 07:43:53PM -0400, Stephen Frost wrote:
>> > * hubert depesz lubaczewski (dep...@depesz.com) wrote:
>> > > create table some_data (id int4 primary key, payload
On 23 July 2013 06:10, Tom Lane wrote:
> Andrew Gierth writes:
>> I must admit to finding all of this criticism of unread code a bit
>> bizarre.
>
> If you yourself are still finding bugs in the code as of this afternoon,
> onlookers could be forgiven for doubting that the code is quite as
> read
On 19 July 2013 04:09, Greg Smith wrote:
> On 7/18/13 11:03 PM, Stephen Frost wrote:
>>
>> Wasn't there a wiki page about this
>> feature which might also help? Bigger question- is it correct for the
>> latest version of the patch?
>
>
> https://wiki.postgresql.org/wiki/RLS has accumulated a lot
On 18 July 2013 22:27, Stephen Frost wrote:
> Dean,
>
>
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Thanks! This is really looking quite good, but it's a bit late and I'm
>> going on vacation tomorrow, so I didn't quite want to commit it yet. :)
>
> Apologies on this taking a bit longer than
On 19 June 2013 18:12, Peter Eisentraut wrote:
> On 6/19/13 11:50 AM, Dean Rasheed wrote:
>> On 19 June 2013 15:22, Peter Eisentraut wrote:
>>> We still don't have any support for this in psql, do we?
>>>
>>
>> No, but at least we now have an API that
On 11 July 2013 00:03, Bernd Helmle wrote:
>
>
> --On 8. Juli 2013 16:04:31 +0000 Dean Rasheed
> wrote:
>
>> * pg_relation_is_updatable is only available in 9.3, whereas psql may
>> connect to older servers, so it needs to guard against that.
>>
>
> Oh of
On 8 July 2013 12:46, Bernd Helmle wrote:
> Recently i got annoyed that psql doesn't tab complete to updatable foreign
> tables.
>
> Attached is a patch to address this. I'm using the new
> pg_relation_is_updatable() function to accomplish this. The function could
> also be used for the trigger ba
On 5 July 2013 18:23, David Fetter wrote:
> Please find attached changes based on the above.
>
This looks good. The grammar changes are smaller and neater now on top
of the makeFuncCall() patch.
Overall I think this patch offers useful additional functionality, in
compliance with the SQL spec, w
On 5 July 2013 07:02, Pavel Stehule wrote:
> Hello
>
> I try to check this patch
>
> I have a problem with initdb after patching
>
> error
>
> initializing dependencies ... ok
> creating system views ... FATAL: WITH CHECK OPTION is supported only
> on auto-updatable views
> STATEMENT: /*
>
>
> I
On 4 July 2013 00:08, David Fetter wrote:
> Patch re-jiggered for recent changes to master.
>
I re-validated this, and it all still looks good, so still ready for
committer IMO.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
On 1 July 2013 01:44, David Fetter wrote:
> On Fri, Jun 28, 2013 at 09:22:52PM +0100, Dean Rasheed wrote:
>> On 21 June 2013 06:16, David Fetter wrote:
>> > Please find attached a patch which allows subqueries in the FILTER
>> > clause and adds regression testing for
On 1 July 2013 03:07, Nicholas White wrote:
> I've attached another iteration of the patch that fixes the multiple-window
> bug and adds (& uses) a function to create a Bitmapset using a custom
> allocator. I don't think there's any outstanding problems with it now.
>
I just realised there is ano
On 1 July 2013 03:07, Nicholas White wrote:
>> Alternatively, it might be trivial to make all aggregate functions work
>> with ignore nulls in a window context
>
> This is a good idea, but I'd like to keep the scope of this patch limited
> for the time being
Agreed.
> - I'll look at doing this
On 29 June 2013 17:30, Jeff Davis wrote:
>
> On Mon, 2013-06-24 at 18:01 +0100, Nicholas White wrote:
>> Good catch - I've attached a patch to address your point 1. It now
>> returns the below (i.e. correctly doesn't fill in the saved value if
>> the index is out of the window. However, I'm not su
On 21 June 2013 06:16, David Fetter wrote:
> Please find attached a patch which allows subqueries in the FILTER
> clause and adds regression testing for same.
>
This needs re-basing/merging following Robert's recent commit to make
OVER unreserved.
Regards,
Dean
--
Sent via pgsql-hackers maili
On 27 June 2013 15:05, Tom Lane wrote:
> Andrew Gierth writes:
>> Tom Lane said:
>>> Agreed, separating out the function-call-with-trailing-declaration
>>> syntaxes so they aren't considered in FROM and index_elem seems like
>>> the best compromise.
>>>
>>> If we do that for window function OVER
On 27 June 2013 17:47, Peter Eisentraut wrote:
> On 6/27/13 4:19 AM, Dean Rasheed wrote:
>> I'd say there are clearly people who want it, and the nature of some
>> of those answers suggests to me that we ought to have a better answer
>> in core.
>
> It's no
On 26 June 2013 21:46, Peter Eisentraut wrote:
> On 6/26/13 4:04 PM, Dean Rasheed wrote:
>> A quick google search reveals several people asking for something like
>> this, and people recommending md5(string_agg(...)) or
>> md5(string_agg(md5(...))) based solutions, which
On 26 June 2013 22:48, Noah Misch wrote:
> On Wed, Jun 26, 2013 at 09:04:34PM +0100, Dean Rasheed wrote:
>> On 26 June 2013 19:32, Noah Misch wrote:
>> > On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
>
>> > md5_agg() is well-defined and not cryptog
On 26 June 2013 19:32, Noah Misch wrote:
> On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
>> I've been playing around with the idea of an aggregate that computes
>> the sum of the md5 hashes of each of its inputs, which I've called
>> md5_to
On 26 June 2013 01:01, Josh Berkus wrote:
>
>> I know it's heresy in these parts, but maybe we should consider
>> adopting a non-spec syntax for this feature? In particular, it's
>> really un-obvious why the FILTER clause shouldn't be inside rather
>> than outside the aggregate's parens, like ORD
On 26 June 2013 01:22, Josh Berkus wrote:
> Folks,
>
> (the below was already discussed on IRC)
>
> Leaving names aside on this patch, I'm wondering about a piece of
> functionality I have with the current unnest() and with the
> unnest_ordinality()[1] extension: namely, the ability to unnest seve
On 25 June 2013 18:17, Josh Berkus wrote:
> Hackers,
>
> I'd like to take a straw poll here on how we should acknowledge
> reviewers. Please answer the below with your thoughts, either on-list
> or via private email.
>
> How should reviewers get credited in the release notes?
>
> a) not at all
>
On 24 June 2013 03:50, Tom Lane wrote:
> David Fetter writes:
>> On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote:
>>> I think it is OK if that gets a syntax error. If that's the "worst
>>> case" I like this approach.
>
>> I think reducing the usefulness of error messages is someth
On 24 June 2013 04:29, Josh Berkus wrote:
> On 06/23/2013 08:00 PM, Andrew Gierth wrote:
>> OK, let's try to cover all the bases here in one go.
>
>> 1. Stick with "?column?" as a warning flag that you're not supposed to
>> be using this without aliasing it to something.
>
> How do I actually supp
On 21 June 2013 08:31, Dean Rasheed wrote:
> On 21 June 2013 08:02, Dean Rasheed wrote:
>> On 21 June 2013 06:54, David Fetter wrote:
>>>> For example "SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS file"
>>>
>>> The spec is pretty s
On 21 June 2013 21:04, David Fetter wrote:
> On Fri, Jun 21, 2013 at 10:48:35AM -0700, David Fetter wrote:
>> On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
>> > On 15 June 2013 10:22, Dean Rasheed wrote:
>> > > There seem to be 2 separate direct
On 21 June 2013 10:02, Dean Rasheed wrote:
> On 21 June 2013 06:16, David Fetter wrote:
>> On Fri, Jun 21, 2013 at 12:10:25AM -0400, Alvaro Herrera wrote:
>>> David Fetter escribió:
>>> > On Thu, Jun 20, 2013 at 08:59:27PM +0100, Dean Rasheed wrote:
>>>
On 21 June 2013 06:16, David Fetter wrote:
> On Fri, Jun 21, 2013 at 12:10:25AM -0400, Alvaro Herrera wrote:
>> David Fetter escribió:
>> > On Thu, Jun 20, 2013 at 08:59:27PM +0100, Dean Rasheed wrote:
>>
>> > > In my testing of sub-queries in the FILTER cla
On 21 June 2013 05:01, David Fetter wrote:
> What tests do you think should be there that aren't?
>
I think I expected to see more tests related to some of the specific
code changes, such as
CREATE TABLE t AS SELECT * FROM generate_series(1,10) t(x);
-- Should fail (filter can't be used for non
On 21 June 2013 08:02, Dean Rasheed wrote:
> On 21 June 2013 06:54, David Fetter wrote:
>>> For example "SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS file"
>>
>> The spec is pretty specific about the "all or none" nature of naming
&
On 21 June 2013 06:54, David Fetter wrote:
>> For example "SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS file"
>
> The spec is pretty specific about the "all or none" nature of naming
> in the AS clause...unless we can figure out a way of getting around it
> somehow.
We already support and docu
On 17 June 2013 06:36, David Fetter wrote:
>> > > Please find attached two versions of a patch which provides optional
>> > > FILTER clause for aggregates (T612, "Advanced OLAP operations").
>> > >
>> > > The first is intended to be applied on top of the previous patch, the
>> > > second without i
On 19 June 2013 18:12, Peter Eisentraut wrote:
> On 6/19/13 11:50 AM, Dean Rasheed wrote:
>> On 19 June 2013 15:22, Peter Eisentraut wrote:
>>> We still don't have any support for this in psql, do we?
>>>
>>
>> No, but at least we now have an API that
On 19 June 2013 15:22, Peter Eisentraut wrote:
> We still don't have any support for this in psql, do we?
>
No, but at least we now have an API that psql can use.
There are still a number of questions about the best way to display it in psql.
Should it be another column in \d+'s list of relation
On 19 June 2013 04:11, David Fetter wrote:
> On Tue, Jun 18, 2013 at 11:36:08AM +0100, Dean Rasheed wrote:
>> On 17 June 2013 06:33, David Fetter wrote:
>> >> Next revision of the patch, now with more stability. Thanks, Andrew!
>> >
>> > Rebased vs. gi
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
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 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 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 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 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.
>
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 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
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 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 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 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 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 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 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 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 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 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
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 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
On 16 May 2013 22:16, Tom Lane wrote:
> This is assuming that an FDW that defines, say, ExecForeignDelete
> is thereby promising that *all* tables it supports are deletable. That
> is not required by the current FDW API spec.
>
Ah OK, I didn't appreciate that distinction.
> If we want to do som
Hi,
I've just started 9.3 beta testing and I noticed that a "simple" view
defined on top of a writable foreign table is not automatically
updatable.
Given that these are both new-to-9.3 features, I think it would be a
shame if they don't work together. It's basically a 1-line patch to
make such v
an view here:
>
> http://momjian.us/pgsql_docs/release-9-3.html
>
> I will be working on polishing them for the next ten days, so any
> feedback, patches, or commits are welcome. I still need to add lots of
> SGML markup.
>
E.1.3.4.4. VIEWs:
* Make simple views auto-updatabl
On 3 April 2013 15:10, Tom Lane wrote:
> I think though that the upthread argument that we'd have multiple
> interpretations of the same thing is bogus. To me, the core idea that's
> being suggested here is that '{}' should mean a zero-length 1-D array,
> not a zero-D array as formerly. We would
301 - 400 of 616 matches
Mail list logo
