On Tue, Jun 7, 2016 at 12:23 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Tue, Jun 7, 2016 at 1:35 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >> I have finally given a shot at improving the docs with the attached.
On Tue, Jun 7, 2016 at 1:35 AM, Michael Paquier
wrote:
> On Fri, Jun 3, 2016 at 11:25 PM, Tom Lane wrote:
> > Michael Paquier writes:
> >> Actually, the docs could be more polished.
> >
> > I think the docs could stand to be rewritten from scratch ;-). But
> > upthread there was an offer to wo
On Tue, Jun 7, 2016 at 1:35 AM, Michael Paquier
wrote:
> On Fri, Jun 3, 2016 at 11:25 PM, Tom Lane wrote:
> > Michael Paquier writes:
> >> Actually, the docs could be more polished.
> >
> > I think the docs could stand to be rewritten from scratch ;-). But
> > upthread there was an offer to wo
On Mon, Jun 6, 2016 at 3:26 PM, Tom Lane wrote:
> Robert Haas writes:
> > ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1.
> > I really don't like #1 much - I think I'd almost rather do nothing.
>
> FWIW, that's about my evaluation of the alternatives as well. I fear
> that #1 would
On Mon, Jun 6, 2016 at 2:31 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
> > On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
> > > Robert Haas writes:
> > >> On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> > >>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
> > >>>
On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> >> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
> >> have the same behavior as before if the SRFs all return the same number
> >> of rows, and ot
On Mon, Jun 6, 2016 at 11:45 AM, Bruce Momjian *EXTERN*
wrote:
>
> One more thing --- there was talk of moving some of this into chapter
> 66, but as someone already mentioned, there are no subsections there
> because it is a dedicated topic:
>
> 66. How the Planner Uses Statistics.
> I
On Mon, Jun 6, 2016 at 7:17 AM, Sridhar N Bamandlapally <
sridhar@gmail.com> wrote:
> Hi
>
> Is there any option in PGPLSQL which can RETURNS table or SETOF rows along
> with an OUT parameter?
>
>
No, there would be no point given the internals of how functions work.
What is it you are tryi
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
On Friday, June 3, 2016, Tom Lane > wrote:
> Merlin Moncure writes:
> > On Wed, May 25, 2016 at 3:55 PM, Tom Lane wrote:
> >> Andres Freund writes:
> >>> If we go with rewriting this into LATERAL, I'd vote for 2.5 (trailed by
> >>> option 1), that'd keep most of the functionality, and would bre
On Wed, Jun 1, 2016 at 12:07 AM, sri harsha wrote:
>
> Hi,
>
> In PostgreSQL , does the order in which the criteria is given matter
> ?? For example
>
> Query 1 : Select * from TABLE where a > 5 and b < 10;
>
> Query 2 : Select * from TABLE where b <10 and a > 5;
>
> Are query 1 and query 2 t
On Fri, Jun 3, 2016 at 1:55 PM, Robert Haas wrote:
> On Wed, Jun 1, 2016 at 5:59 PM, David G. Johnston
> wrote:
> > Maybe I don't understand PGDLLEXPORT...
>
> We're talking about PGDLLIMPORT.
>
Typo, was thinking "we export this for others to consume&q
On Fri, Jun 3, 2016 at 10:41 AM, Thom Brown wrote:
> On 3 June 2016 at 15:26, David G. Johnston
> wrote:
>
>> On Fri, Jun 3, 2016 at 9:56 AM, Tom Lane wrote:
>>
>>> Thom Brown writes:
>>> > ...or at least according to the warning message:
On Fri, Jun 3, 2016 at 9:56 AM, Tom Lane wrote:
> Thom Brown writes:
> > ...or at least according to the warning message:
> > postgres=# CREATE EXTENSION chkpass ;
> > WARNING: type input function chkpass_in should not be volatile
>
> See thread here:
>
>
> https://www.postgresql.org/message-id
On Fri, Jun 3, 2016 at 8:20 AM, Robert Haas wrote:
> On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus wrote:
> > I was assuming that we would have *both* per-operation and per-statement
> > limits. I can see reasons for having both, I can see why power users
> > would want both, but it's going to be
On Fri, Jun 3, 2016 at 3:17 AM, Albe Laurenz
wrote:
>
> > I'd maybe go with something like this:
> >
> > All executions of a prepared statement having zero parameters will use
> the same plan so the planning
> > time taken during the first execution will be spread across all
> subsequent executio
On Thu, Jun 2, 2016 at 9:56 PM, Bruce Momjian wrote:
> In Postgres 9.2 we improved the logic of when generic plans are used by
> EXECUTE. We weren't sure how well it would work, and the docs included
> a vague description on when generic plans are chosen.
>
> I have gotten a few questions lately
On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus wrote:
> On 06/02/2016 01:08 PM, David G. Johnston wrote:
> > On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus > <mailto:j...@agliodbs.com>>wrote:
> >
> > On 06/02/2016 08:53 AM, Tom Lane wrote:
> > > Jos
On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus wrote:
> On 06/02/2016 08:53 AM, Tom Lane wrote:
> > Josh berkus writes:
> >> On 06/02/2016 04:58 AM, Robert Haas wrote:
> >>> Well, I think we could drop node, if you like. I think parallel
> >>> wouldn't be good to drop, though, because it sounds li
On Thu, Jun 2, 2016 at 9:59 AM, Tom Lane wrote:
> Robert Haas writes:
> > Well, I think we could drop node, if you like. I think parallel
> > wouldn't be good to drop, though, because it sounds like we want a
> > global limit on parallel workers also, and that can't be just
> > max_workers. So
On Wed, Jun 1, 2016 at 5:40 PM, Tom Lane wrote:
> > On Wed, Jun 1, 2016 at 5:04 PM, Robert Haas
> wrote:
> >> Probably not, but yes, I do want to reduce the commit load. I also
> >> think that we essentially have a contract with our users to limit what
> >> we back-patch to critical bug fixes an
On Wed, Jun 1, 2016 at 5:04 PM, Robert Haas wrote:
> On Wed, Jun 1, 2016 at 12:24 PM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> On Wed, Jun 1, 2016 at 12:06 AM, Craig Ringer
> wrote:
> >> > On 1 June 2016 at 11:48, Michael Paquier
> wrote:
> >> >> Could it be possible to mark Postmas
On Tue, May 31, 2016 at 6:20 PM, Tom Lane wrote:
> David Fetter writes:
> > On Tue, May 31, 2016 at 05:06:00PM -0400, David G. Johnston wrote:
> >> While likely not that common the introduction of an ambiguity makes
> >> raises the bar considerably.
>
> > W
On Wed, Jun 1, 2016 at 11:55 AM, Jim Nasby wrote:
> On 5/31/16 7:04 PM, Peter van Hardenberg wrote:
>
>> The idea of converting a JSONB array to a PG array is appealing and
>> would potentially be more general-purpose than adding a new unnest. I'm
>> not sure how feasible either suggestion is.
>>
On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek wrote:
> That GUC also controls worker processes that are started by extensions,
> not just ones that parallel query starts. This is btw one thing I don't
> like at all about how the current limits work, the parallel query will
> fight for workers wit
On Wed, Jun 1, 2016 at 9:00 AM, Robert Haas wrote:
> On Wed, Jun 1, 2016 at 12:06 AM, Craig Ringer
> wrote:
> > On 1 June 2016 at 11:48, Michael Paquier
> wrote:
> >> Could it be possible to mark PostmasterPid with PGDLLIMPORT on HEAD
> >> and back-branches?
> >
> > Sounds sensible to me.
>
>
All,
Oven in the "JSON[B] arrays are second-class citizens" thread [1] I made
the observation that the only way to get a PostgreSQL array from a JSON
array is via the "elements->cast->array_agg" chain. For JSON arrays that
are homogeneous in nature the capability to go "directly" from JSON to
jso
On Tue, May 31, 2016 at 5:46 PM, David Fetter wrote:
> On Tue, May 31, 2016 at 05:06:00PM -0400, David G. Johnston wrote:
> > On Tue, May 31, 2016 at 4:34 PM, David Fetter wrote:
> >
> > > Folks,
> > >
> > > While querying some JSONB blobs at work in
On Tue, May 31, 2016 at 4:34 PM, David Fetter wrote:
> Folks,
>
> While querying some JSONB blobs at work in preparation for a massive
> rework of the data infrastructure, I ran into things that really
> puzzled me, to wit:
>
> SELECT * FROM unnest('["a","b","c"]'::jsonb);
> ERROR: function unne
On Tue, May 31, 2016 at 4:12 PM, Robert Haas wrote:
> On Tue, May 31, 2016 at 4:04 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Robert Haas wrote:
> >>> So I think in the long run we should have three limits:
> >>>
> >>> 1. Cluster-wide limit on number of worker processes for all purpose
On Tue, May 31, 2016 at 3:55 PM, Nikolay Shaplov
wrote:
> В письме от 31 мая 2016 15:38:38 пользователь Robert Haas написал:
>
> > >>> 99% of the time, you'd be right. But this is an unusual case, for
> the
> > >>> reasons I mentioned before.
> > >>
> > >> I tend to agree with Nikolay. I can't
On Tue, May 31, 2016 at 3:35 PM, Robert Haas wrote:
> On Tue, May 31, 2016 at 3:19 PM, Tom Lane wrote:
> > I wrote:
> >> At the risk of opening another can of worms, what about renaming
> >> max_worker_processes as well? It would be a good thing if that
> >> had "cluster" in it somewhere, or so
On Tue, May 31, 2016 at 3:19 PM, Tom Lane wrote:
> I wrote:
> > At the risk of opening another can of worms, what about renaming
> > max_worker_processes as well? It would be a good thing if that
> > had "cluster" in it somewhere, or something that indicates it's a
> > system-wide value not a pe
On Tue, May 31, 2016 at 2:19 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 5/31/16 1:47 PM, Jaime Casanova wrote:
>
>> Are we going to change synchronous_standby_names? Certainly the GUC is
>> not *only* a list of names anymore.
>>
>> synchronous_standby_config?
>> synchrono
On Tue, May 31, 2016 at 2:37 PM, Josh berkus wrote:
> On 05/31/2016 11:27 AM, Peter Geoghegan wrote:
> > On Tue, May 31, 2016 at 11:22 AM, Josh berkus wrote:
> >>> I think we can hope that developers are going to be less confused about
> >>> that than users.
> >>
> >> Makes sense.
> >
> > Maybe
On Tue, May 31, 2016 at 2:22 PM, Josh berkus wrote:
> On 05/31/2016 11:17 AM, Peter Eisentraut wrote:
> > On 5/31/16 2:02 PM, Josh berkus wrote:
> >> I get where you're coming from, but I think Haas's query plan output is
> >> going to show us the confusion we're going to get. So we need to eith
On Tuesday, May 31, 2016, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 11:02 AM, Josh berkus > wrote:
> > I get where you're coming from, but I think Haas's query plan output is
> > going to show us the confusion we're going to get. So we need to either
> > change the parameter, the explain
On Tuesday, May 31, 2016, Tom Lane wrote:
> I wrote:
> > I really think that a GUC named "max_parallel_workers", which in fact
> > limits the number of workers and not something else, is the way to go.
>
> To be concrete, I suggest comparing the attached documentation patch
> with Robert's. Whic
On Tuesday, May 31, 2016, Tom Lane wrote:
> Josh berkus > writes:
> > On 05/31/2016 10:16 AM, Peter Geoghegan wrote:
> >> But the distinction between parallel workers and backends that can
> >> participate in parallel query does need to be user-visible. Worker
> >> processes are a commodity (i.e.
On Sun, May 29, 2016 at 1:28 PM, Emre Hasegeli wrote:
> Attached patch adds regexp_match() function which is a simple variant of
> regexp_matches() that doesn't return a set. It is based on Tom Lane's
> comment to bug #10889 [1].
>
> [1] https://www.postgresql.org/message-id/23769.1404747...@sss
On Fri, May 27, 2016 at 6:02 AM, Craig Ringer wrote:
>
> COPY FROM $1 TO 'myfilename'
>
>
Random thought - how about at least making the following work:
For the following pretend that "STRING" has the same behavior as the
"format(...)" function.
EXECUTE STRING('COPY %I TO %L', 'testtable',
On Thu, May 26, 2016 at 8:09 AM, Nikolay Shaplov
wrote:
> В письме от 24 мая 2016 12:47:20 пользователь Tom Lane написал:
> > Nikolay Shaplov writes:
> > > If I read gram.y code for insert statement, I see that there is an
> > > optional
> > > USING keyword before opclass name
> > >
> > > opt_cl
Moving my griping to -hackers only
On Tue, May 24, 2016 at 8:08 PM, Tom Lane wrote:
> dig...@126.com writes:
> > postgres=# create unlogged table u_tbl (id int);
> > CREATE TABLE
> > postgres=# create index idx_u_tbl on u_tbl using bloom (id);
> > ERROR: index "idx_u_tbl" already contains data
On Tue, May 24, 2016 at 4:07 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, May 24, 2016 at 3:57 PM, Tom Lane wrote:
>
>> "David G. Johnston" writes:
>> > I just noticed this comment in scan.l:
>> > /*
>> > * GUC vari
On Tue, May 24, 2016 at 3:57 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > I just noticed this comment in scan.l:
> > /*
> > * GUC variables. This is a DIRECT violation of the warning given at the
> > * head of gram.y, ie flex/bison code m
I just noticed this comment in scan.l:
/*
* GUC variables. This is a DIRECT violation of the warning given at the
* head of gram.y, ie flex/bison code must not depend on any GUC variables;
* as such, changing their values can induce very unintuitive behavior.
* But we shall have to live with
On Mon, May 23, 2016 at 5:38 PM, Jim Nasby wrote:
> On 5/23/16 11:55 AM, Peter van Hardenberg wrote:
>
>> Fortunately, this seems quite easy to resolve by taking advantage of our
>> ability to add json_*(jsonb) form of the functions.
>>
>
> Another issue no one has mentioned is functions that ret
On Mon, May 23, 2016 at 4:42 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Mon, May 23, 2016 at 4:24 PM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
> >> Ah, so that's what "pipeline results" mean! I hadn'
On Mon, May 23, 2016 at 4:37 PM, Tom Lane wrote:
> Peter van Hardenberg writes:
> > Great question, Marko. If you can point me towards an example I'll take a
> > look, but I'll proceed with the current understanding and suggestions and
> > see what people have to say.
>
> I believe Marko's just
On Mon, May 23, 2016 at 4:24 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
> > Joe Conway writes:
>
> > > I'll also note that, unless I missed something, we also have to
> consider
> > > that the capability to pipeline results is still only available in the
> > > target list.
> >
> > Yes, we would
On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> Merlin Moncure writes:
> > On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote:
> >> On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote:
> >>> +1 on removing LCM.
>
> >> As a green field project, that would make total sense. As a t
On Mon, May 23, 2016 at 4:05 PM, David Fetter wrote:
> On Mon, May 23, 2016 at 02:39:54PM -0500, Merlin Moncure wrote:
> > On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote:
> > > On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote:
> > >> On Mon, May 23, 2016 at 12:10 PM, Tom Lane
On Mon, May 23, 2016 at 1:44 PM, David Fetter wrote:
> On Mon, May 23, 2016 at 01:36:57PM -0400, Tom Lane wrote:
> > David Fetter writes:
> > > On Mon, May 23, 2016 at 01:10:29PM -0400, Tom Lane wrote:
> > >> This seems a bridge too far to me. It's just way too common to do
> > >> "select gener
On Mon, May 23, 2016 at 12:55 PM, Peter van Hardenberg wrote:
> Hi there,
>
> I noticed it was very easy to accidentally call the json_* form of JSON
> manipulation functions with jsonb data as input. This is pretty
> sub-optimal, since it involves rendering the jsonb then reparsing it and
> call
On Mon, May 23, 2016 at 12:01 PM, Jeff Davis wrote:
> On Fri, May 20, 2016 at 1:41 PM, David G. Johnston
> wrote:
> > How does the relatively new FILTER clause play into this, if at all?
>
> My interpretation of the standard is that FILTER is not allowable for
> a window
On Sun, May 22, 2016 at 6:53 PM, Teodor Sigaev wrote:
>
> to_tsquery(' Berkus & "PostgreSQL Version 10.0" ')
>>
>> ... would be equivalent to:
>>
>> to_tsquery(' Berkus & ( PostgreSQL <-> version <-> 10.0 )')
>>
>
> select to_tsquery('Berkus') && phraseto_tsquery('PostgreSQL Version 10.0');
> doe
tl;dr
Semantic changes to SRF-in-target-list processing are undesirable when they
are all but deprecated.
I'd accept a refactoring that trades a performance gain for unaffected
queries for a reasonable performance hit of those afflicted.
Preamble...
Most recent thread that I can recall seeing o
On Sun, May 22, 2016 at 3:00 PM, Thom Brown wrote:
> On 22 May 2016 at 18:52, Josh berkus wrote:
> > Folks,
> >
> > This came up at pgCon.
> >
> > The 'word <-> word <-> word' syntax for phrase search is not
> > developer-friendly. While we need the <-> operator for SQL and for the
> > sophisti
On Sat, May 21, 2016 at 10:32 AM, Euler Taveira
wrote:
> On 20-05-2016 20:34, Robert Haas wrote:
> > Hmm, my experience is different. I use EXPLAIN (ANALYZE, VERBOSE) a
> > lot, but EXPLAIN (ANALYZE, BUFFERS) only rarely. I wonder if a GUC is
> > the way to go.
> >
> I wouldn't like a command o
Just doing a drive-by...
On Fri, May 20, 2016 at 3:50 PM, Jeff Davis wrote:
> Old thread link:
>
> http://www.postgresql.org/message-id/CA+=vxna5_n1q5q5okxc0aqnndbo2ru6gvw+86wk+onsunjd...@mail.gmail.com
>
> On Thu, Apr 14, 2016 at 1:29 PM, Stephen Frost wrote:
> > Jeff
> >
> > (Reviving an old
On Thursday, May 19, 2016, David Christensen wrote:
>
> > On May 19, 2016, at 3:17 PM, Евгений Шишкин > wrote:
> >
> >
> >> On 19 May 2016, at 22:59, Tom Lane >
> wrote:
> >>
> >> David Christensen > writes:
> >>> This simple patch adds “ALL” as an EXPLAIN option as shorthand for
> “EXPLAIN (ANA
On Tue, May 17, 2016 at 12:15 PM, Shay Rojansky wrote:
> Apologies, as usual I didn't read the docs carefully enough.
>
> On Tue, May 17, 2016 at 7:13 PM, Tom Lane wrote:
>
>> Shay Rojansky writes:
>> > A user of mine just raised a strange issue... While it is possible to
>> use a
>> > paramete
On Fri, May 13, 2016 at 10:18 PM, Mark Dilger
wrote:
>
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence.
You started this sub-thread with:
"If I understand correctly..."
I'm not sure that you do...
Our scheme is, in you
On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake
wrote:
> On 05/13/2016 07:42 AM, Robert Haas wrote:
>
>> On Sat, Apr 30, 2016 at 8:46 PM, Joshua Drake
>> wrote:
>>
>>> Oh, absolutely. I was just pointing out how a lot of companies are
>>> hoarding
>>> talent internally for no productive purpos
On Fri, May 13, 2016 at 6:05 PM, Joshua D. Drake
wrote:
> On 05/13/2016 01:42 PM, Josh berkus wrote:
>
>> On 05/13/2016 01:04 PM, Joshua D. Drake wrote:
>>
>>> On 05/13/2016 12:03 PM, Josh berkus wrote:
>>>
On 05/13/2016 11:48 AM, Robert Haas wrote:
> On Fri, May 13, 2016 at 12:12 P
On Fri, May 13, 2016 at 7:32 PM, Mark Dilger
wrote:
>
> Any project that starts inflating its numbering scheme sends a message to
> users of the form, "hey, we've just been taken over by marketing people,
> and
> software quality will go down from now on."
>
Tom brought up my own thoughts on th
On Fri, May 13, 2016 at 6:44 PM, Michael Banck wrote:
> On Fri, May 13, 2016 at 05:31:00PM -0400, David G. Johnston wrote:
> > The underlying premise, for me, of choosing .4 or .5 was that presently
> we
> > discontinue support after 5 years/releases. A new .0 would come
On Friday, May 13, 2016, Tom Lane wrote:
> Robert Haas > writes:
> > On Fri, May 13, 2016 at 2:49 PM, Tom Lane > wrote:
>
> > If we don't want to stick with the current practice of debating when
> > to bump the same digit, then let's agree that 10.0 will follow 9.6 and
> > after that we'll bump
On Thursday, May 12, 2016, Tom Lane wrote:
> "David G. Johnston" > writes:
> > On Thursday, May 12, 2016, Tom Lane
> > ');>>
> wrote:
> >> (I'm not particularly in love with the node type name
> >> ValueFunction; anybody got a be
On Thursday, May 12, 2016, Tom Lane > wrote:
>
> So what I've wanted to do for some time is invent a new expression node
> type that represents any one of these functions and can be reverse-listed
> in the same format that the input had. The attached proposed patch does
> that. (I'm not particul
On Wed, May 11, 2016 at 10:38 AM, Robert Haas wrote:
> On Wed, May 11, 2016 at 12:34 AM, Tom Lane wrote:
> >> Hmm, that is strange. I would have expected that to stuff a Gather on
> >> top of the Aggregate. I wonder why it's not doing that.
> >
> > The reason is that create_plain_partial_paths
On Wed, May 11, 2016 at 9:54 AM, Robert Haas wrote:
> On Tue, May 10, 2016 at 9:16 PM, David G. Johnston
> wrote:
> > Brute force: you'd have to query pg_amop and note the absence of a row
> with
> > a btree (maybe hash too...) family strategy 3 (1 for hash) [equality
On Tuesday, May 10, 2016, Euler Taveira wrote:
>
> Also, IS DISTINCT FROM is an alias for = operator per standard IIRC.
>
Technically "is not distinct from" would be more correct. Alias implies
exact while in the presence of nulls the two behave differently.
"is distinct from" ~ "<>" which is
On Saturday, May 7, 2016, Euler Taveira wrote:
> On 07-05-2016 22:53, Robins Tharakan wrote:
> > Should I be looking somewhere else? Parse keywords from Git Source file
> > (if so where)? Parse PG Documentation?
> >
> src/include/parser/kwlist.h
>
http://www.postgresql.org/docs/9.5/interactive
On Tuesday, May 10, 2016, David E. Wheeler wrote:
>
> This makes sense, of course, and I could fix it by comparing text values
> instead of json values when the values are JSON. But of course the lack of
> a = operator is not limited to JSON. So I’m wondering if there’s an
> interface at the SQL
On Mon, May 9, 2016 at 8:53 AM, Benedikt Grundmann <
bgrundm...@janestreet.com> wrote:
> We just run into a very simple query that the planner does much worse on
> than we thought it would (in production the table in question is ~ 100
> GB). It surprised us given the planner is generally quite go
On Sunday, May 8, 2016, Tom Lane wrote:
> [ I think you meant to attach this to the other thread, but anyway... ]
This is where the link to the online version was; reading the sgml
and/or compiling ends up being a bit more than I wanted to do to review
these.
>
> "David G. John
On Sun, May 8, 2016 at 10:56 AM, Robert Haas wrote:
> On Sat, May 7, 2016 at 11:42 PM, David G. Johnston
> wrote:
> > All of the other planner GUCs are basically, {on, off, special} with on
> or
> > special the default as appropriate for the feature - since most/all
>
On Saturday, May 7, 2016, Tom Lane wrote:
> Stephen Frost > writes:
> > * Tom Lane (t...@sss.pgh.pa.us ) wrote:
> >> ... but I'm left with a policy question: should initdb disallow
> >> bootstrap superuser names like "pg_xxx"?
>
> > On the whole, I'd vote to treat the bootstrap user as a normal r
On Friday, May 6, 2016, Tom Lane wrote:
> If you're not tired of reviewing release notes (I'm sure getting a bit
> tired of writing them), see
>
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=eb7de00ac2d282263541ece849ec71e2809e9467
>
> guaibasaurus should have 'em up on th
My take below is that of a user reading our documentation and our projected
consistency via that document.
All of the other planner GUCs are basically, {on, off, special} with on or
special the default as appropriate for the feature - since most/all
features default to enabled. While I get that t
On Monday, February 8, 2016, Vitaly Burovoy
wrote:
>
> 12. At the same time in (subcl. 4.13) mentioned there can be "at least
> one NNC" (may be via inheritance?).
>
>
This is a bit hard to reason about given that our implementation of
inheritance is non-standard.
Are we close to the standard se
Quick flyby here...
On Tuesday, May 3, 2016, Tom Lane wrote:
> Vitaly Burovoy > writes:
> > On 4/27/16, Alvaro Herrera >
> wrote:
> >> Point 2 is where things differ from what I remember; my (possibly
> >> flawed) understanding was that there's no difference between those
> >> things. Many (may
On Mon, May 2, 2016 at 12:03 PM, Rodrigo Cavalcante
wrote:
> Hi,
>
> On alternate days my backup is failing, by the pg_stop_backup process ()
> does not perform or quit.
>
> Version PostgreSQL: 9.1.6
>
Reporting unusual behavior while running a years-old point release is
unlikely to be producti
On Tue, May 3, 2016 at 5:51 AM, hari.prasath
wrote:
> Hi all,
> How postgresql handles full table delete in terms of loading the
> full table in these scenarios
>
> consider one big table(tablename: bigtable)
> and the query will be >> delete from bigtable;
>
> 1)which doesn't have any fore
On Mon, May 2, 2016 at 12:14 PM, Robert Haas wrote:
> On Mon, May 2, 2016 at 2:44 PM, David G. Johnston
> wrote:
> > Does this apply to the extent that a value of 1 is likely worse than 0
> since
> > the leader is now tasked with accumulating but there is only one process
On Sun, Apr 24, 2016 at 8:01 PM, Robert Haas wrote:
>
> Of course, we could make this value 1-based rather than 0-based, as
> Peter Geoghegan suggested a while back. But as I think I said at the
> time, I think that's more misleading than helpful. The leader
> participates in the parallel plan,
On Fri, Apr 29, 2016 at 4:19 PM, Tom Lane wrote:
> Alvaro Herrera writes:
> > Andreas Karlsson wrote:
> >> I am currently looking into adding the correct parallel options to all
> >> functions in the extensions and I noticed that some built-in functions
> seems
> >> to have been marked as unsafe
On Fri, Apr 29, 2016 at 1:47 PM, Bruce Momjian wrote:
> On Wed, Apr 13, 2016 at 12:57:19PM -0300, Marcelo Zabani wrote:
> > Hi, Tom,
> >
> > You're right, I don't think one can argue that the default parser should
> know
> > HTML.
> > How about your suggestion of there being an HTML parser, is it
On Fri, Apr 29, 2016 at 7:15 AM, Merlin Moncure wrote:
> Andrew mentions several solutions. I like them all except I would
> prefer not to introduce a GUC for controlling the output format. I do
> not think it's a good idea to set the expectation that clients can
> rely on text out byte for byt
On Thursday, April 28, 2016, Simon Riggs wrote:
> On 27 April 2016 at 17:04, Craig Ringer > wrote:
>
>> On 27 April 2016 at 21:44, Tom Lane > > wrote:
>>
>>> Petr Jelinek >> > writes:
>>> > +1 (Abhijit's wording with data loss changed to data corruption)
>>>
>>> I'd suggest something like
>>>
>>
On Thu, Apr 28, 2016 at 10:00 AM, Ryan Pedela
wrote:
> On Tue, Apr 26, 2016 at 10:49 AM, Stephen Frost
> wrote:
>
>> * Ryan Pedela (rped...@datalanche.com) wrote:
>> > On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni
>> wrote:
>> > > The default text representation of jsonb adds whitespace in b
On Sun, Apr 24, 2016 at 3:02 PM, Sehrope Sarkuni wrote:
> Attached is a *very* work in progress patch that adds a
> jsonb_compact(jsonb)::text function. It generates a text representation
> without extra whitespace but does not yet try to enforce a stable order of
> the properties within a jsonb
On Sun, Apr 24, 2016 at 3:02 PM, Sehrope Sarkuni wrote:
> It'd be nice to have a stable text representation of a jsonb value with
> minimal whitespace. The latter would also save a few bytes per record in
> text output formats, on the wire, and in backups (ex: COPY ... TO STDOUT).
>
>
Attached
http://www.postgresql.org/docs/9.5/interactive/app-psql.html
"""
\t
Toggles the display of output column name headings and row count footer.
This command is equivalent to \pset tuples_only and is provided for
convenience.
"""
Experience says that a table caption (i.e., \C) is also suppressed wh
On Thu, Apr 21, 2016 at 8:26 AM, Andrea Adami wrote:
>
> Hello, i'm a developer from italy and i need to make a query to get the
> list of stored procedures with its signature.
> Basically I would like to get the same list pgAdmin shows under the node
> functions of the database tree on left pane
On Fri, Apr 15, 2016 at 8:56 AM, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Wed, Apr 13, 2016 at 6:53 PM, Stephen Frost
> wrote:
> > > Requiring that SET ROLE be allowed will mean that many more paths must
> > > be checked and adjusted, such as in all
201 - 300 of 608 matches
Mail list logo
