On Thu, Jan 26, 2017 at 12:37 PM, Andres Freund wrote:
> On 2017-01-26 14:28:01 -0500, Robert Haas wrote:
> > On Thu, Jan 26, 2017 at 2:24 PM, Andres Freund
> wrote:
> > >> Whether the voters recognized that fact at the time I would have to
> concur
> > >> that if we are going to change from xlo
On Thu, Jan 26, 2017 at 12:13 PM, Andres Freund wrote:
> On 2017-01-26 14:05:43 -0500, Robert Haas wrote:
> > I completely understand that position. I have always been doubtful of
> > the value of renaming pg_xlog to pg_wal, and I'm not any more
> > dedicated to the idea now than I was when I co
On Thursday, January 26, 2017, Michael Banck
wrote:
> On Thu, Jan 26, 2017 at 12:37:44PM -0500, Peter Eisentraut wrote:
> > On 1/24/17 8:19 AM, Tom Lane wrote:
> > > What about just saying that the database owner has those privileges?
> > > After all, the ultimate privilege of an owner is to drop
On Wed, Oct 5, 2016 at 2:03 AM, Fabien COELHO wrote:
>
> I've got no objection to a more-nearly-TPC-B script as an option.
>>
>
> Good, because adding a "per-spec" tpc-b as an additional builtin option is
> one of my intentions, once pgbench is capable of it.
Trying to scan the thread as an in
On Mon, Jan 23, 2017 at 11:16 AM, Fabien COELHO wrote:
>
> [...] Obviously the \if stuff is things we don't have yet either, but it
>>> seems less likely to have surprising side-effects.
>>>
>>
> I agree, a more generic solution seems better than an ad-hoc one.
>
> Currently the value of a non ex
On Mon, Jan 23, 2017 at 10:34 AM, Corey Huinker
wrote:
> I was giving some thought to how psql handles undefined variables.
>
> I would like an option where either psql can provide an alternate value
> when an undefined variable is referenced, or a way to detect that a
> specific variable is unde
On Wed, Jan 18, 2017 at 4:14 PM, Tom Lane wrote:
> I wrote:
> > I'll try to write something about the SRF-in-CASE issue too. Seeing
> > whether we can document that adequately seems like an important part
> > of making the decision about whether we need to block it.
>
> Here's what I came up wit
On Wed, Jan 18, 2017 at 3:15 PM, Justin Pryzby wrote:
> Is this expected behavior ?
>
> ts=# SELECT * FROM t WHERE site_id=32768 LIMIT 1;
> (0 rows)
>
> ts=# PREPARE x AS SELECT * FROM t WHERE site_id=$1 LIMIT 1;
> PREPARE
> ts=# EXECUTE x(32768);
> ERROR: smallint out of range
>
Probably
On Wed, Dec 21, 2016 at 2:40 PM, Andres Freund wrote:
> That's imo pretty much what progress LSN currently describes. Have there
> been any records which are important for durability/consistency and
> hence need to be archived and such.
>
The above, to me, describes a "milestone LSN"...
David
On Wed, Dec 21, 2016 at 9:49 AM, Tom Lane wrote:
> A possible objection is that if we really are on the hairy edge of OOM,
> trying to construct such error strings might push us over the edge
What am I missing here? Constructing said string occurs on the local end
of the connection but the mem
On Tue, Dec 20, 2016 at 1:49 PM, Tom Lane wrote:
> Peter Eisentraut writes:
> > Maybe the fix is to make --wait the default?
>
> I was wondering about that too ... does anyone remember the rationale
> for the current behavior? But the message for the non-wait case seems
> like it could stand to
On Mon, Dec 19, 2016 at 11:23 AM, Alvaro Herrera
wrote:
> David G. Johnston wrote:
>
> > Being able to do more conditional work in psql would make setting up more
> > robust scripts easier and without either losing transaction capabilities
> or
> > session pooling fo
On Mon, Dec 19, 2016 at 10:30 AM, Robert Haas wrote:
>
> I see your point. Just out of curiosity, why in the world don't you
> use something other than psql for scripting? I mean, if you accessed
> the data from Perl or Python or
> $INSERT_YOUR_FAVORITE_SCRIPTING_LANGUAGE_HERE, you could do all
On Fri, Dec 16, 2016 at 10:28 AM, Pavel Stehule
wrote:
> 2016-12-16 18:21 GMT+01:00 David G. Johnston :
>
>> On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas
>> wrote:
>>
>>>
>>> If the expected committed patch set includes #5 then this becomes a
>&g
On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas wrote:
> On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas
> wrote:
> >> - possible incremental implemention steps on this path:
> >>
> >> (1) minimal condition and expression, compatible with
> >> a possible future full-blown expression syntax
>
On Mon, Dec 12, 2016 at 10:08 PM, Tom Lane wrote:
> Every WHERE clause is a
>
boolean expression, so there's no principled reason why such a rule
> wouldn't result in canonicalizing e.g. "i = 42" into "(i = 42) = true",
> wreaking havoc on every other optimization we have. Restricting it
> to on
On Mon, Dec 12, 2016 at 9:19 AM, Robert Haas wrote:
> So, one of the problems in this patch as committed is that for any
> process that doesn't show up in pg_stat_activity, there's no way to
> see the wait event information. That sucks. I think there are
> basically two ways to fix this:
>
> 1.
On Fri, Dec 9, 2016 at 10:17 AM, Robert Haas wrote:
>
> As Geoff says, you don't have to use the operators; you could use the
> equivalent functions instead. Every operator just gets turned into a
> function call internally, so this is always possible.
>
In most cases - the decision to tie inde
On Fri, Dec 9, 2016 at 4:50 AM, Jordan Gigov wrote:
> There is this problem with the jsonb operators "? text" "?| text[]"
> and "?& text[]" that the question mark is typically used for prepared
> statement parameters in the most used abstraction APIs in Java and
> PHP.
>
Unfortunately true. Th
On Wed, Dec 7, 2016 at 1:03 PM, Tom Lane wrote:
> Still, things have been like this since 8.2 when we implemented multi-row
> VALUES, and nobody's noticed up to now. Maybe the right answer is to
> change the data structure in HEAD and decree that we won't fix it in back
> branches. I don't real
On Mon, Dec 5, 2016 at 9:54 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> The concern is that "scan every row" could be very expensive - though in
> writing this I'm thinking that you'd quickly find a non-match even in a
> large dataset - an
feel free to s/typemod/typmod/ ... my fingers don't want to drop the "e"
On Mon, Dec 5, 2016 at 9:17 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello,
>
> At Mon, 5 Dec 2016 18:59:42 -0700, "David G. Johnston" <
> david.g.joh
On Mon, Dec 5, 2016 at 6:36 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello,
>
> At Mon, 5 Dec 2016 14:42:39 -0700, "David G. Johnston" <
> david.g.johns...@gmail.com> wrote in v8nr0FsCFrQ=oo1dkp...@mail.gmail.com>
> > On M
On Mon, Dec 5, 2016 at 2:22 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote:
> >> In order to fix this, we first have to decide what the semantics ought
> >> to be. I think there are two plausible defini
On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote:
> I looked into the issue reported in bug #14448,
> https://www.postgresql.org/message-id/20161205143037.
> 4377.60754%40wrigleys.postgresql.org
>
> The core of it seems to be that expandRTE() will report the type and
> typmod of a column of a VALUE
On Mon, Nov 28, 2016 at 7:38 PM, Christian Convey <
christian.con...@gmail.com> wrote:
> On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams
> wrote:
>
>> While XPath is expressive and compact, XSLT
>> is rather verbose; jq is as expressive as XSLT, but with the compact
>> verbosity of XPath.
>>
>
> I
On Mon, Nov 28, 2016 at 2:07 PM, Tom Lane wrote:
> Corey Huinker writes:
> > On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO
> wrote:
>
There's no reason to assume a-priori that this patch creates either naming
> conventions or semantics (e.g. what is suitable as a boolean expression)
> that we'
On Tue, Nov 22, 2016 at 3:56 PM, Tom Lane wrote:
> Doc: improve documentation about composite-value usage.
>
> Create a section specifically for the syntactic rules around whole-row
> variable usage, such as expansion of "foo.*". This was previously
> documented only haphazardly, with some criti
On Fri, Nov 4, 2016 at 12:15 PM, Tom Lane wrote:
> Michael Paquier writes:
> > I am passing that down to a committer for review. The patch looks
> > large, but at 95% it involves diffs in the regression tests,
> > alternative outputs taking a large role in the bloat.
>
> This is kind of cute, bu
On Thu, Oct 20, 2016 at 6:03 PM, Robert Haas wrote:
> On Thu, Oct 20, 2016 at 3:46 PM, Tom Lane wrote:
> > I'm mostly with Stephen on this. As the names stand, they encourage
> > people to go look at the documentation,
> > https://www.postgresql.org/docs/devel/static/storage-file-layout.html
>
On Wed, Oct 19, 2016 at 9:29 AM, Bruce Momjian wrote:
> On Tue, Oct 18, 2016 at 04:51:54PM +0200, Andreas Joseph Krogh wrote:
> > > 2. Being able to move pg_largeobject to a different tablespace
> > >*without* turning on system_table_mods. This is important for
> > >people sto
On Tue, Oct 18, 2016 at 10:21 AM, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Tue, Oct 18, 2016 at 9:45 AM, Tom Lane wrote:
> >> One interesting point, if you wish to consider history as being
> >> connection-specific, is what happens during a \c c
On Tue, Oct 18, 2016 at 9:45 AM, Tom Lane wrote:
> Jonathan Jacobson writes:
> > The .psql_history file is naturally used by different DB connections
> > (distinguished by a different combination of host + port + database +
> user).
> > At least in my multi-database working environment, this lea
On Tue, Oct 18, 2016 at 9:26 AM, Jonathan Jacobson wrote:
> The .psql_history file is naturally used by different DB connections
> (distinguished by a different combination of host + port + database + user).
> At least in my multi-database working environment, this leads sometimes to
> frustratio
On Tue, Oct 18, 2016 at 9:26 AM, Jonathan Jacobson wrote:
> The .psql_history file is naturally used by different DB connections
> (distinguished by a different combination of host + port + database + user).
> At least in my multi-database working environment, this leads sometimes to
> frustratio
On Mon, Oct 17, 2016 at 1:39 PM, Jim Nasby wrote:
> On 10/17/16 11:29 AM, Tom Lane wrote:
>
>> Jim Nasby writes:
>>
>>> On 10/16/16 3:13 PM, Tom Lane wrote:
>>>
Related to this I'd also like to add a boolean XOR operator as that's a
> relatively common request/question.
>
>> We
Its considered bad form to post to multiple lists. Please pick the most
relevant one - in this case I'd suggest -general.
On Mon, Sep 26, 2016 at 8:39 AM, dby...@163.com wrote:
>
> Array is not convenient to use in function, whether
> there are other methods can be replaced temp table in functi
On Tue, Aug 16, 2016 at 7:47 PM, Jim Nasby wrote:
> On 8/15/16 10:12 PM, Tom Lane wrote:
>
>> Jim Nasby writes:
>>
>>> Any reason why we can create a function that accepts anyelement and
>>> returns anyarray, but can't do the same with anyrange?
>>>
>>
>> Because there can be more than one range
On Fri, Aug 12, 2016 at 3:03 PM, Robert Haas wrote:
> On Thu, Aug 11, 2016 at 8:34 AM, David G. Johnston
> wrote:
> > I don't have a fundamental issue with saying "when turning auto-commit on
> > you are also requesting that the open transaction, if there is one,
On Thu, Aug 11, 2016 at 2:11 AM, Venkata Balaji N wrote:
>
> [...]
> committing all the previously open transactions
> [...]
>
"All"? There can only ever be at most one open transaction at any given
time...
I don't have a fundamental issue with saying "when turning auto-commit on
you are a
Hackers,
The attached attempts to make comprehension of the code in
"TS_phrase_execute" a bit easier. I posted similar on the "typo patch"
thread of July 2nd/5th but my comments there reflected my mis-understanding
of the distance operator being exact as opposed to the expected
less-than-or-equal
On Mon, Aug 8, 2016 at 11:02 AM, Robert Haas wrote:
> On Mon, Aug 8, 2016 at 10:10 AM, Rahila Syed
> wrote:
> > Thank you for inputs everyone.
> >
> > The opinions on this thread can be classified into following
> > 1. Commit
> > 2. Rollback
> > 3. Error
> > 4. Warning
> >
> > As per opinion upt
Basically,
diff --git a/src/backend/parser/parse_param.c
b/src/backend/parser/parse_param.c
index b402843..97064fc 100644
--- a/src/backend/parser/parse_param.c
+++ b/src/backend/parser/parse_param.c
@@ -108,6 +108,9 @@ fixed_paramref_hook(ParseState *pstate, ParamRef *pref)
ereport(ERROR,
(er
On Thu, Aug 4, 2016 at 4:50 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Aug 2, 2016 at 5:42 PM, David G. Johnston
> > wrote:
> > The fact that pg_dump is emitting COMMENT ON DATABASE at all is
> > fundamentally wrong given the existing division-of-labor
"\echo" has "\qecho" - I'm basically looking for a "\qprint"
"\write" doesn't apply
The following doesn't work either...
#bash (stock Ubuntu 14.04)
psql --set=query_in_var='SELECT version();' > /dev/null <<'SQL'
\o /tmp/psql-test.txt
\set ECHO queries
--still ends up on stdout, hence the redirec
On Thu, Aug 4, 2016 at 9:25 AM, Robert Haas wrote:
> On Thu, Aug 4, 2016 at 12:56 AM, Tom Lane wrote:
> > Noah Misch writes:
> >> On Wed, Apr 20, 2016 at 02:28:15PM -0400, Tom Lane wrote:
> >>> +1, but let's put an entry on the 9.6 open-items page to remind us to
> >>> make that decision at the
On Wed, Aug 3, 2016 at 1:20 PM, Tom Lane wrote:
> Greg Stark writes:
> > Right now git-describe --tags on a random revision between 9.4
> > and 9.5 will print something like REL9_4_BETA1-1973-g85c25fd or
> > something like REL9_5_BETA2-33-g55a2cc8 if it happens to be after a
> > beta. It's reall
On Wed, Aug 3, 2016 at 12:51 PM, Greg Stark wrote:
> On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane wrote:
> > I thought we'd pretty much done that cleanup during the cvs->git
> > conversion?
>
> I guess I'm talking about tags. I'm not clear on the distinction
> between tags and branches names in git.
Moving to -hackers since this is getting into details
Bug Report # 14247
On Tue, Aug 2, 2016 at 4:58 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > Do you have an opinion on this following?
>
> I think the real problem in this area is that the division o
On Mon, Aug 1, 2016 at 1:41 PM, Tom Lane wrote:
> Over the past couple of months I have already found myself
> writing "10.0" or "9.7^H^H^H10" to make it clear that I meant the next
> release version, because just "10" seemed too ambiguous.
I thought that was just (and maybe some instances wer
On Mon, Aug 1, 2016 at 10:19 AM, Tom Lane wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Building on the has-property approach Andrew suggested, I wonder if
> >> we need something like pg_index_column_has_property(indexoid, colno,
> >> propertyname) with propertie
On Sat, Jul 30, 2016 at 10:35 AM, Tom Lane wrote:
> Greg Stark writes:
> > I think Bruce's summary is a bit revisionist.
>
> I would say it's a tempest in a teapot.
>
> What I think we should do is accept "kb" and the rest case-insensitively,
> print them all in all-upper-case always, and tell s
On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote:
> On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference: 14244
> > Logged by: Thomas Berger
> > Email address: thomas.ber...@1und1
On Tue, Jul 26, 2016 at 11:10 AM, Tom Lane wrote:
>
> 3. Andrew also revived the bug #7808 thread in which it was complained
> that ExecMakeTableFunctionResult should not fail on null results from
> functions returning SETOF composite. That's related only in that the
> proposed fix is to transla
On Friday, July 22, 2016, Andrew Gierth wrote:
> >>>>> "David" == David G Johnston > writes:
>
> >> Prohibiting IS NOT NULL is not on the cards; it's very widely used.
>
> David> Yet changing how it behaves, invisibly, is?
>
>
On Fri, Jul 22, 2016 at 8:04 PM, Andrew Gierth
wrote:
> >>>>> "David" == David G Johnston writes:
>
> >> 2. x IS NOT NULL if and only if NOT (x IS NULL)
>
> David> I would rather prohibit "IS NOT NULL" altogether. If one needs
>
On Fri, Jul 22, 2016 at 7:01 PM, Andrew Gierth
wrote:
> In light of the fact that it is an endless cause of bugs both in pg and
> potentially to applications, I propose that we cease attempting to
> conform to the spec's definition of IS NULL in favour of the following
> rules:
>
> 1. x IS NULL
On Fri, Jul 22, 2016 at 3:04 PM, Merlin Moncure wrote:
> On Fri, Jul 22, 2016 at 1:39 PM, David G. Johnston
> wrote:
> > On Fri, Jul 22, 2016 at 2:13 PM, Tom Lane wrote:
> >>
> >> There is a rather squishy question as to whether NULL::composite_type
> >&g
On Fri, Jul 22, 2016 at 2:13 PM, Tom Lane wrote:
> There is a rather squishy question as to whether NULL::composite_type
> should be semantically equivalent to ROW(NULL,NULL,...)::composite_type.
> If it is, then the SELECT should have failed before even getting into the
> plpgsql function, becau
On Thu, Jul 21, 2016 at 1:57 PM, Jean-Pierre Pelletier <
jppellet...@e-djuster.com> wrote:
>
> I'm puzzled as to how search_path should be used,.
> Should all references be schema qualified inside functions body ?
>
Pretty much...you can also do:
CREATE FUNCTION funcname()
SET search_path TO 'o
On Wed, Jul 20, 2016 at 5:38 PM, Bruce Momjian wrote:
> I think the 'ORDER BY x COLLATE "C"' is being parsed as an a_expr, and
> we don't allow a_expr in a UNION. Perhaps we are too strict here, but I
> can't tell.
>
ORDER BY 1 COLLATE "C" is indeed an expression - the number no longer
refers
On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote:
>
> Hello Tom,
>
> Although "\;" behavior is not documented, I would have expected both
>>> results to be shown one after the other, or having a an error, but not a
>>> quiet discard.
>>>
>>
>> See the documentation for PQexec(): all but the l
On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote:
>
>> I do not think changing this is appropriate. All you are likely to
>> accomplish is breaking code that does what its author wanted.
>>
>
> Hmmm... My 0.02€: Currently this feature is NOT documented, so somehow it
> is not supported, and
On Wed, Jul 13, 2016 at 4:02 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO
> wrote:
> >> If someone thinks that "gset" is a good idea for pgbench, which I
> don't, it
> >> could be implemented. I think that an "into" feature, like PL/pgSQL &
> ECPG,
On Wed, Jul 13, 2016 at 4:47 PM, Fabien COELHO wrote:
>
> I would suggest that:
> - the \; psql feature should be documented somewhere
>
agreed
> - all results should be shown, not just the last one
>
disagree
# select 1 ; select 2 ;
?column?
--
1
(1 row)
?column?
-
On Tue, Jul 5, 2016 at 11:54 AM, Robert Haas wrote:
> On Sat, Jul 2, 2016 at 12:17 PM, CharSyam wrote:
> > I fixed typos. and attached patch for this.
> > Thanks.
> >
> > I only changed comments only in src/backend/utils/adt/tsvector_op.c
>
> Well, that's definitely a typo. However, typo or no
On Tue, Jul 5, 2016 at 5:22 AM, Andreas 'ads' Scherbaum <
adsm...@wars-nicht.de> wrote:
> On 05.07.2016 04:33, David G. Johnston wrote:
>
>> On Mon, Jul 4, 2016 at 8:39 PM, Andreas 'ads' Scherbaum
>> mailto:adsm...@wars-nicht.de>>wrote:
On Mon, Jul 4, 2016 at 8:39 PM, Andreas 'ads' Scherbaum <
adsm...@wars-nicht.de> wrote:
> On 04.07.2016 18:37, Pavel Stehule wrote:
>
>>
>> I don't know if the name "strict" is best, but the name "validate" is
>> not good too. Current to_date does some validations too.
>>
>
> Obviously not enough,
On Sat, Jul 2, 2016 at 8:31 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> Em sábado, 2 de julho de 2016, David G. Johnston <
> david.g.johns...@gmail.com> escreveu:
>
>> On Sat, Jul 2, 2016 at 12:55 PM, Marko Tiikkaja wrote:
>>
>&g
On Sat, Jul 2, 2016 at 12:55 PM, Marko Tiikkaja wrote:
>
> What I would prefer is something like this:
>
> CREATE TABLE foo(
> f1 int NOT NULL COMMENT
> 'the first field',
> f2 int NOT NULL COMMENT
> 'the second field',
> ...
> );
>
> which would ensure the comments are both next to t
https://www.postgresql.org/docs/9.6/static/using-explain.html
Existing...
14.1.2 Explain Analyze
[...]
"""
In some query plans, it is possible for a subplan node to be executed more
than once. For example, the inner index scan will be executed once per
outer row in the above nested-loop plan. In
On Mon, Jun 20, 2016 at 2:54 AM, Masahiko Sawada
wrote:
> >> QUERY PLAN
> >>
> >>
> -
> >> Final
More specifically...
On Wed, Jun 29, 2016 at 7:34 AM, Michael Paquier
wrote:
> On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov
> wrote:
> > Hello!
> >
> > Got some strange behavior of random() function:
> >
> > postgres=# select (select random() ) from generate_series(1,10) as i;
> > random
On Fri, Jun 24, 2016 at 6:41 PM, Andrey Zhidenkov <
andrey.zhiden...@gmail.com> wrote:
> For example, when I call this procedure
> many times,
Call how? Specifically, how are you handling transactions in the calling
client? And what/how are you measuring memory consumption?
David J.
On Fri, Jun 24, 2016 at 1:08 PM, Joshua D. Drake
wrote:
> On 06/23/2016 08:00 PM, Alvaro Herrera wrote:
>
>> Joshua D. Drake wrote:
>>
>>> Hey,
>>>
>>> So this came across my twitter feed:
>>>
>>> https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png
>>>
>>> I have verified the oddness with a newer ver
On Thu, Jun 23, 2016 at 2:00 PM, Robert Haas wrote:
> On Thu, Jun 23, 2016 at 1:46 PM, David G. Johnston
> wrote:
> >> Sheesh. Who put you in charge of this? You basically seem like you
> >> are trying to shut up anyone who supports this change, and I don&#
On Thursday, June 23, 2016, Robert Haas wrote:
> On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston
> > wrote:
> > to_timestamp with its present behavior is, IMO, a poorly designed
> function
> > that would never be accepted today. Concrete proposals for either
> fi
On Thursday, June 23, 2016, Alex Ignatov wrote:
> Arguing just like that one can say that we don't even need exception like
> "division by zero". Just use well-formed numbers in denominator...
> Input data sometimes can be generated automagically. Without exception
> throwing debugging stored fu
On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov
wrote:
>
> On 23.06.2016 16:30, Bruce Momjian wrote:
>
>> On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote:
>>
>>> On Monday, 20 June 2016 8:53 PM, Alex Ignatov
>>> wrote:
>>>
>>>
>>> On 13.06.2016 18:52, amul sul wrote:
>
And it wo
On Mon, Jun 20, 2016 at 5:47 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:52 PM, David G. Johnston
> wrote:
> > Internal or external I do think the number and type of flags described
> here,
> > for the purposes described, seems undesirable from an architectural
>
On Mon, Jun 20, 2016 at 5:08 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake
> wrote:
> > Or we could adopt the very reasonable and practical policy of:
> >
> > The current versioning scheme isn't broke, so we aren't going to fix it.
>
> Yeah, no kidding. We had a perf
On Mon, Jun 20, 2016 at 4:03 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 3:29 PM, David G. Johnston
> wrote:
> > The entire theory here looks whacked - and seems to fall into the "GUCs
> > controlling results" bucket of undesirable things.
>
> As far
On Mon, Jun 20, 2016 at 4:14 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> wrote:
> > 10.x is the desired output.
>
> 10.x is the output that some people desire. A significant number of
> people, including me, would prefer to stick with the
On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger
wrote:
>
> > Do you have a problem with the human form and machine forms of the
> version number being different in this respect? I don't - for me the
> decision of a choice for the human form is not influenced by the fact the
> machine form has 6 dig
On Mon, Jun 20, 2016 at 3:07 PM, Gražvydas Valeika
wrote:
> Hi,
>
> I recently bumped into http://semver.org/
>
> It can be interesting to participants of this discussion.
>
> Especially motivation for minor version (middle number).
>
>
While we appreciate the comment this is third (maybe forth)
On Mon, Jun 20, 2016 at 12:06 PM, Robert Haas wrote:
> On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote:
> >> although I fear we
> >> might be getting to a level of tinkering with parallel query that
> >> starts to look more like feature development.
> >
> > Personally, I'm +1 for such tinkering
On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger
wrote:
>
> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake
> wrote:
> >
> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
> >
> >>> Now maybe you have some other idea in mind, but I don't quite
> >>> understand what it is.
> >>
> >> I do, indeed, and her
On Mon, Jun 20, 2016 at 1:48 PM, Mark Dilger
wrote:
>
> > On Jun 20, 2016, at 9:38 AM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> >
> > On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger
> wrote:
> >
> > > On Jun 20, 2016, at 8:53 AM,
On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger
wrote:
>
> > On Jun 20, 2016, at 8:53 AM, Mark Dilger
> wrote:
> >
> >
> > This is not a plea for keeping the three part versioning system. It's
> just
> > a plea not to have a 2 part versioning system masquerading as a three
> > part versioning sys
On Monday, June 20, 2016, Mark Dilger wrote:
>
> > On Jun 18, 2016, at 5:48 PM, Josh Berkus > wrote:
> >
> > On 06/16/2016 11:01 PM, Craig Ringer wrote:
> >>
> >> I thought about raising this, but I think in the end it's replacing one
> >> confusing and weird versioning scheme for another confus
On Mon, Jun 20, 2016 at 8:19 AM, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas
> wrote:
> > On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote:
> >> amul sul writes:
> >>> It's look like bug in to_timestamp() function when format string has
> more whitespaces compare to inpu
On Sat, Jun 18, 2016 at 4:52 PM, Thangalin wrote:
tl/dr; Observations, thoughts, and questions present inline as well.
Note, I'm drawing a conclusion below but do not have the code knowledge to
know for certain that what I describe doesn't have holes in it. I'm also
assuming a bit about what
On Fri, Jun 17, 2016 at 2:23 PM, Aleksey Demakov wrote:
> On Fri, Jun 17, 2016 at 10:54 PM, Robert Haas
> wrote:
> > On Fri, Jun 17, 2016 at 12:34 PM, Aleksey Demakov
> wrote:
> >>> I expect that to be useful for parallel query and anything else where
> >>> processes need to share variable-size
On Fri, Jun 17, 2016 at 2:01 AM, Craig Ringer wrote:
> On 17 June 2016 at 08:34, Greg Stark wrote:
>
>> So we would release 10.0.0 and 10.0.1 and the next major release would be
>> 11.0.0.
>>
>> This would have two benefits:
>>
>> 1) It emphasises that minor releases continue to be safe minor up
On Wed, Jun 15, 2016 at 3:40 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
> > On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera
> > wrote:
>
> > > We actually go quite some lengths to support this case, even when it's
> > > the opinion of many that we shouldn't. For example VACUUM doesn't tr
On Wed, Jun 15, 2016 at 12:09 PM, Jimmy wrote:
> Not sure if this was discussed in the past and decided it does not belong
> to pg_isready utility
>
> I am using pg_isready in dockerized development environment as part of
> docker-compose. Simply say I have POSTGRES container and APP containe
On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure wrote:
> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
> wrote:
> > On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure
> wrote:
> >>
> >> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby
> >> wrote:
On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure wrote:
> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby
> wrote:
> > On 6/14/16 3:56 PM, Tom Lane wrote:
> >>
> >> Jim Nasby writes:
> >>>
> >>> On 6/14/16 3:01 PM, Robert Haas wrote:
>
> This seems kind of silly, because anybody who is writ
On Mon, Jun 13, 2016 at 3:40 PM, br...@momjian.us wrote:
>
> > > Looking at how the code behaves, it seems custom plans that are _more_
> > > expensive (plus planning cost) than the generic plan switch to the
> > > generic plan after five executions, as now documented. Custom plans
> > > that ar
On Fri, Jun 10, 2016 at 4:11 AM, Sridhar N Bamandlapally <
sridhar@gmail.com> wrote:
> Hi
>
> Is there any feature in PostgreSQL where online DW (Dataware housing) is
> possible ?
>
> am looking for scenario like
>
> 1. Production DB will have CURRENT + LAST 7 DAYS data only
>
> 2. Archive/DW
101 - 200 of 608 matches
Mail list logo
