On Tue, 22 Mar 2016 at 10:34 Robert Haas wrote:
> Yeah, I think requiring PERFORM is stupid and annoying. +1 for
> letting people write a SELECT with no target.
>
Apologies for being late on the thread, but another +1 from me. I've often
been frustrated by the dissonance of PERFORM against SQL
On Tuesday, March 22, 2016, Merlin Moncure wrote:
>
> Anyways, here's the patch with documentation adjustments as promised.
> I ended up keeping the 'without result' section because it contained
> useful information about plan caching,
>
> merlin
>
> diff --git a/doc/src/sgml/plpgsql.sgml b/doc/s
On Friday, May 6, 2016, Robert Haas wrote:
> On Fri, May 6, 2016 at 2:38 PM, Merlin Moncure > wrote:
> > On Fri, Mar 25, 2016 at 8:36 AM, Merlin Moncure > wrote:
> >> On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost > wrote:
> >>> Just a thought. I do still like the general idea of INE support
On Thursday, March 17, 2016, Craig Ringer wrote:
> The first patch was incorrectly created on top of failover slots not HEAD.
> Attached patch applies on HEAD.
>
Lots of logical decoding work ongoing but this one shows as active in the
September cf and the comments by Craig indicate potential re
On Saturday, June 4, 2016, Emre Hasegeli wrote:
> > The main problem being solved is the use of a SETOF result. I'm
> inclined to
> > prefer that the final, single, result is still an array.
>
> I have changed it like that. New patch attached.
Good
>
> > I've got a style issue with the info
David Rowley writes:
> I think your wires are crossed to what this patch actually does. A
> unique index could only prove that no more than 1 rows exists. This
> goes to prove that exactly 1 exists, then will reduce that estimate by
> any other join conditions which were not matched to a foreign k
On Thu, Jun 02, 2016 at 04:00:33PM +0900, Michael Paquier wrote:
> On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier
> wrote:
> > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier
> > wrote:
> >> I have added an open item for 9.6 regarding this patch, that would be
> >> good to complete this work in
On Fri, Jun 03, 2016 at 10:32:24AM -0400, Noah Misch wrote:
> On Wed, Jun 01, 2016 at 09:29:54PM -0400, Noah Misch wrote:
> > On Sun, May 29, 2016 at 01:36:01AM -0400, Noah Misch wrote:
> > > On Fri, May 06, 2016 at 03:06:01PM -0400, Robert Haas wrote:
> > > > On Thu, May 5, 2016 at 10:48 AM, David
On Fri, Jun 3, 2016 at 4:24 PM, Kevin Grittner wrote:
> Consequently, causing the index to be ignored in planning when
> using the old index
That last line should have read "using an old snapshot"
> is not a nice optimization, but necessary for
> correctness. We already have logic to do this f
This is a branch of the discussion in
https://www.postgresql.org/message-id/flat/20160429102531.GA13701%40huehner.biz
but I'm starting a new thread as the original title is getting
increasingly off-topic.
I complained in that thread that the FK join selectivity patch had a
very brute-force approac
Robert Haas writes:
> FYI, I spoke to Tom Lane about this at PGCon and suggested that he
> look at the proposed patch as I requested in
> https://www.postgresql.org/message-id/CA+TgmobPqrAVXOBMHTcpDq8hX7gCzcVhoUvC8s9V=d09+bt...@mail.gmail.com
> and see whether that would address his concerns, and
Michael Paquier writes:
> This is still failing:
> =# select indexdef from pg_catalog.pg_indexes where indexdef is not NULL;
> ERROR: XX000: cache lookup failed for index 2619
> LOCATION: pg_get_indexdef_worker, ruleutils.c:1054
> Do we want to improve at least the error message?
Maybe we shoul
On Fri, Aug 7, 2015 at 9:21 AM, Tom Lane wrote:
> Andreas Seltenreich writes:
>> Tom Lane writes:
>>> On 08/01/2015 05:59 PM, Tom Lane wrote:
Well, I certainly think all of these represent bugs:
1 | ERROR: could not find pathkey item to sort
>
>>> Hmm ... I see no error with these quer
> The main problem being solved is the use of a SETOF result. I'm inclined to
> prefer that the final, single, result is still an array.
I have changed it like that. New patch attached.
> I've got a style issue with the information_schema - I like to call it
> useless-use-of-E'' - but that was
14 matches
Mail list logo
