On Thu, Mar 19, 2015 at 3:41 PM, David Christensen
wrote:
> The two-arg form of the current_setting() function will allow a
> fallback value to be returned instead of throwing an error when an
> unknown GUC is provided. This would come in most useful when using
> custom GUCs; e.g.:
>
> -- retu
On Tue, Oct 31, 2017 at 4:31 PM, Tels wrote:
>
>
> That looks odd to me, it first uses output_tuples in a formula, then
> overwrites the value with a new value. Should these lines be swapped?
>
IIUC it is correct: the additional total_cost comes from processing every
output group to check wh
On Tue, Oct 31, 2017 at 3:43 PM, Tom Lane wrote:
> According to the spec, the elements of a parenthesized
> SET list should be assigned from the fields of a composite RHS. If
> there's just one element of the SET list, the RHS should be a single-field
> composite value, and this syntax should re
On Tue, Oct 31, 2017 at 3:14 PM, Rob McColl wrote:
>
>> I believe that this is not an intended change or behavior, but is instead
>> an unintentional side effect of 906bfcad7ba7cb3863fe0e2a7810be8e3cd84fbd
>> Improve handling of "UPDATE ... SET (column_list) = row_constructor". (
>> https://githu
Since CREATE USER is officially an alias for CREATE ROLE other parts of the
documentation should point to CREATE ROLE, not CREATE USER. Most do but I
noticed when looking at CREATE DATABASE that it did not. Further searching
turned up the usage in client-auth.sgml. That one is questionable since
On Wed, Oct 18, 2017 at 2:30 PM, Nico Williams
wrote:
> On Wed, Oct 18, 2017 at 02:13:29PM -0700, David G. Johnston wrote:
> > > More useful than this, for me, would be a way to get the top-most user.
> >
> > That would be "session_user"?
>
> It's not
On Wed, Oct 18, 2017 at 2:08 PM, Nico Williams
wrote:
> On Wed, Oct 18, 2017 at 01:43:30PM -0700, David G. Johnston wrote:
>
> More useful than this, for me, would be a way to get the top-most user.
>
>
That would be "session_user"?
> Introducing the concept of a
On Wed, Oct 18, 2017 at 1:26 PM, Nico Williams
wrote:
> On Wed, Oct 18, 2017 at 10:15:01PM +0200, Pavel Stehule wrote:
> > there is a function session_user() already
>
> But it doesn't do this. Are you saying that I should add a
> session_user(int)?
>
>
Regardless of the merits of the proposed
diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml
index 116f7224da..f1f7cfed5f 100644
--- a/doc/src/sgml/release-10.sgml
+++ b/doc/src/sgml/release-10.sgml
@@ -242,7 +242,7 @@
This changes pg_basebackup's
- -X/--xlog-method default to
stream.
+ -X/--w
On Thu, Oct 5, 2017 at 3:05 PM, Joshua D. Drake
wrote:
> On 10/05/2017 02:54 PM, David G. Johnston wrote:
>
>> On Thu, Oct 5, 2017 at 2:37 PM, Joshua D. Drake > <mailto:j...@commandprompt.com>>wrote:
>>
>> I get being able to change my search_path on the
On Thu, Oct 5, 2017 at 2:37 PM, Joshua D. Drake
wrote:
> I get being able to change my search_path on the fly but it seems odd that
> as user foo I can change my default search path?
>
Seems down-right thoughtful of us to allow users to change their own
defaults instead of forcing them to always
On Tue, Sep 19, 2017 at 11:29 AM, Tom Lane wrote:
> T
> hat
>
> doesn't work today, and this patch doesn't fix it, but it does create
> enough confusion that we never would be able to fix it.
>
> I'd be much happier if there were some notational difference
> between I-want-the-composite-var
On Tue, Sep 19, 2017 at 2:12 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > Actually, this does work, just not the way one would immediately expect.
>
> On closer inspection, what's actually happening in your example is that
> you're getting the SELE
On Tue, Sep 19, 2017 at 11:29 AM, Tom Lane wrote:
> Aside from being inconsistent, it doesn't cover all
> the cases --- what if you have just one query output column, that is
> composite, and you'd like it to go into a composite variable? That
> doesn't work today, and this patch doesn't fix it,
On Tuesday, September 19, 2017, Tom Lane wrote:
> Pavel Stehule > writes:
> > 2017-09-14 12:33 GMT+02:00 Anthony Bykov >:
> >> As far as I understand, this patch adds functionality (correct me if I'm
> >> wrong) for users. Shouldn't there be any changes in doc/src/sgml/ with
> the
> >> descripti
On Thursday, September 14, 2017, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 3:23 AM, Tsunakawa, Takayuki
> > wrote:
> > Sorry again, but how can we handle this? A non-PG-developer, Tels (and
> possibly someone else, IIRC) claimed that the behavior be changed during
> the beta period. Why shou
On Thu, Sep 14, 2017 at 8:41 AM, Stephen Frost wrote:
> Robert, all,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>
> > >
> > > I vote for rejecting it. DDL compatibility is less valuable than other
> > > compatibility. The hypothetical affected application can change its
> DDL to
> > > pla
On Wed, Sep 13, 2017 at 12:46 PM, Fabien COELHO wrote:
>
> Hello Tom,
>
> Probably it needs some rebase after Tom committed result status variables.
>>>
>>
>> As it is a style thing, ISTM that the patch is ready if most people agree
>>> that it is better this way and there is no strong veto again
On Fri, Sep 8, 2017 at 2:09 PM, Tom Lane wrote:
> Pavel Stehule writes:
> > personally I prefer syntax without FOR keyword - because following
> keyword
> > must be reserved keyword
>
> > SET x = .., y = .. SELECT ... ;
>
> Nope. Most of the statement-starting keywords are *not* fully reserved;
On Wed, Aug 30, 2017 at 4:08 PM, Bossart, Nathan
wrote:
> On 8/30/17, 5:37 PM, "Michael Paquier" wrote:
> > Yeah... Each approach has its cost and its advantages. It may be
> > better to wait for more opinions, no many people have complained yet
> > that for example a list of columns using twice
On Mon, Aug 28, 2017 at 2:26 AM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> https://www.postgresql.org/docs/devel/static/runtime-config-client.html
>
> >
> V
> ACUUM performs an aggressive scan
>
Maybe this should gets its own thread/patch but I'll tack this on here
since it
On Mon, Aug 21, 2017 at 2:30 PM, Simon Riggs wrote:
>
> > The patch applies cleanly to current master and all tests run without
> > failures.
> >
> > I also test against all current supported versions (9.2 ... 9.6) and
> didn't
> > find any issue.
> >
> > Changed status to "ready for commiter".
>
On Tue, Aug 8, 2017 at 8:34 PM, Tom Lane wrote:
> A small suggestion is that it'd be better to write it like "Specified
> upper bound \"%s\" precedes lower bound \"%s\"." I think "succeeds" has
> more alternate meanings than "precedes", so the wording you have seems
> more confusing than it need
On Tue, Aug 8, 2017 at 4:33 PM, Dean Rasheed
wrote:
> On 8 August 2017 at 19:22, Robert Haas wrote:
> > On Fri, Jul 21, 2017 at 4:24 AM, Dean Rasheed
> wrote:
> >> Also drop the constraint prohibiting finite values after an unbounded
> >> column, and just document the fact that any values after
On Thu, Aug 3, 2017 at 8:53 AM, Tom Lane wrote:
> Robert Haas writes:
> > So maybe --load-via-partition-root if nobody likes my previous
> > suggestion of --partition-data-via-root ?
>
> WFM.
>
+1
David J.
On Thursday, August 3, 2017, Rushabh Lathia
wrote:
>
>
> --use-partitioned-table [partitioned_name, ...] # if
> names are omitted it defaults to all the partitioned tables.
>
> Here user need to specify the root relation name in the option - and any
> partition table have that as a ROOT, will loa
On Wed, Aug 2, 2017 at 10:58 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Aug 2, 2017 at 1:08 PM, Tom Lane wrote:
> >> --restore-via-partition-root ?
>
> > I worry someone will think that pg_dump is now restoring stuff, but it
> isn't.
>
> Well, the point is that the commands it emits
On Tue, Aug 1, 2017 at 8:39 AM, Nick Dro wrote:
> The operator <> seems to not work properly comparing citext types in
> triggers function.
>
> https://stackoverflow.com/questions/45441840/posgresql-
> 9-3-operator-doesnt-give-logical-result
>
> Can someone figure out what is the problem? This se
On Mon, Jul 31, 2017 at 7:06 PM, Robert Haas wrote:
> On Thu, Jul 13, 2017 at 8:40 PM, Amit Langote
> wrote:
> > On 2017/07/13 19:57, Ashutosh Bapat wrote:
> >> On Thu, Jul 13, 2017 at 12:01 PM, Amit Langote
> >> wrote:
> >>> The description of \d[S+] currently does not mention that it will lis
On Mon, Jul 31, 2017 at 5:42 PM, Amit Langote wrote:
>
> On a second thought though, I think we should list the foreign table
> partitions' limitations in only one place, that is, the CREATE FOREIGN
> TABLE reference page. Listing them under 5.10.2.3. seems a bit off to me,
> because other limit
On Tue, Jul 25, 2017 at 11:29 PM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> > I'm curious what the other limitations are...
>
> When I first wrote that documentation line (I am assuming you're asking
> about "although these have some limitations that normal tables do not"), I
> was th
On Thu, Jul 20, 2017 at 6:53 AM, Tom Lane wrote:
> tushar writes:
> > postgres=# create table t(n int);
> > CREATE TABLE
> > postgres=# create table t1(a int);
> > CREATE TABLE
> > postgres=# create view ttt1 as SELECT e.n FROM t e NATURAL LEFT JOIN t1
> d;
> > CREATE VIEW
>
> You realize of cou
On Thursday, July 13, 2017, Tom Lane wrote:
>
> regression=# select * from fdc();
> fdc
> ---
> (1,2)
> (1 row)
>
>
Select (fdc).* from fdc(); is considerably more intuitive that the cast.
Does that give the expected multi-column result?
David J.
On Thursday, July 13, 2017, Tom Lane wrote:
> Maybe we can hack ruleutils to use
> the CAST syntax only in this specific context.
>
Given the lack of complaints, and ubiquity of ::, this would seem ideal
and sufficient. While there is something to be said for using standard
compliant syntax chan
On Mon, Jun 26, 2017 at 12:19 PM, David Fetter wrote:
> On Mon, Jun 26, 2017 at 04:00:55PM +0200, Joel Jacobson wrote:
> > Hi hackers,
> >
> > A colleague of mine wondered if there is a way to always run
> > everything you type into psql in a db txn and automatically rollback
> > it as soon as it
On Wed, Jun 21, 2017 at 12:15 PM, Robert Haas wrote:
> I think the problem is real,
> but I'm not sure that this is the best solution. On the other hand,
> I'm also not entirely sure I understand the proposal yet.
Given the problems with changing the protocol it does seem like
generalizing away
On Tue, Jun 20, 2017 at 1:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 20, 2017 at 2:34 PM, Peter Eisentraut
>> wrote:
>>> This was not a typo, this was intentional.
>
>> To me, Julien's change seems to make it easier to understand, but
>> maybe I'm misunderstanding what it's tryi
On Tue, Jun 20, 2017 at 11:54 AM, Alvaro Herrera
wrote:
> Satyanarayana Narlapuram wrote:
> Unless you have a lot of users running psql manually, I don't see how
> this is actually very useful or actionable. What would the user do with
> the information? Hopefully your users already trust that
On Tue, Jun 20, 2017 at 12:22 PM, Chapman Flack wrote:
> I get the reported result (DELETE 0 and a table containing 2 and 3)
> in both 'read committed' and 'read uncommitted'.
Practically speaking those are a single transaction isolation mode.
https://www.postgresql.org/docs/10/static/transactio
On Tuesday, June 20, 2017, Robert Haas wrote:
> On Tue, Jun 20, 2017 at 2:34 PM, Peter Eisentraut
> > wrote:
> > On 6/18/17 03:16, Julien Rouhaud wrote:
> >> Patch attached.
> >
> > This was not a typo, this was intentional.
>
> To me, Julien's change seems to make it easier to understand, but
>
On Mon, Jun 19, 2017 at 2:53 PM, Tom Lane wrote:
> "David G. Johnston" writes:
>> The docs also indicate that we don't include materialized views as
>> part of "\d" which seems like an oversight somewhere.
>
> Where are you reading that?
https://ww
On Mon, Jun 19, 2017 at 2:25 PM, Peter Eisentraut
wrote:
> On 6/19/17 09:00, Oleksandr Shulgin wrote:
>> I wonder if it is intentional that \d complains on stderr if it cannot
>> find relations to match, but \dt prints the message to the current
>> output file?
>>
>> postgres=# \d xxx
>> Did not f
On Mon, Jun 19, 2017 at 2:10 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> ... If the trigger is succeeding (ie,
>>> detecting a no-op update) often enough that it would be worth that,
>>> you've really got an application-stupidity problem to fix.
>
>> ISTM the whole point o
On Fri, Jun 16, 2017 at 12:40 PM, Cook, Malcolm wrote:
> Hi,
>
>
>
> I am referring to the contents of https://yum.postgresql.org/
> (specifically version 9.6 rpms for CentoOS7)
>
>
>
> More specifically I wonder if they are configured:--with-python
> --with-tcl --with-pam --with-ldap
>
>
>
>
On Thursday, June 15, 2017, Tom Lane wrote:
> Michael Paquier writes:
> > On Fri, Jun 16, 2017 at 1:01 PM, Tom Lane wrote:
> >> (2) My inclination would be not to back-patch. This change could break
> >> configurations that worked before, and the lack of prior complaints
> >> says that not man
On Wed, Jun 14, 2017 at 4:10 PM, Tom Lane wrote:
> I was hoping we'd get some more votes in this thread, but it seems like
> we've only got three, and by my count two of them are for just printing
> "all tables".
The following looks right - given a publication it would nice to know if
its for a
On Thu, Jun 8, 2017 at 8:18 AM, Robert Haas wrote:
> Whatever you put in the hostaddr field - or any field other than host
> and port - is one entry. There is no notion of a list of entries in
> any other field, and no attempt to split any other field on a comma or
> any other symbol.
>
[...]
On Wed, Jun 7, 2017 at 11:57 AM, Tom Lane wrote:
> If people are on board with throwing an error, I'll go see about
> writing a patch.
>
+1 from me.
David J.
Stephen,
On Tue, May 30, 2017 at 8:41 PM, Stephen Frost wrote:
> David,
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Fri, May 26, 2017 at 7:47 AM, Stephen Frost
> wrote:
> > > * Robins Tharakan (thara...@gmail.com) wrote:
> > > > A
On Tue, May 30, 2017 at 8:07 PM, Tom Lane wrote:
> Hm, but with this you're trading that problem for "is the right version
> of pg_config in my PATH?".
>
That is probably a solved problem for those who are parsing the output of
--version today.
>
> This idea might well be useful for external
On Tue, May 30, 2017 at 6:36 PM, Michael Paquier
wrote:
> On Tue, May 30, 2017 at 6:14 PM, Craig Ringer
> wrote:
> > Attached is a small patch to teach pg_config how to output a
> --version-num
> >
> > With Pg 10, parsing versions got more annoying. Especially with
> > "10beta1", "9.6beta2" etc
On Fri, May 26, 2017 at 7:47 AM, Stephen Frost wrote:
> Greetings,
>
> * Robins Tharakan (thara...@gmail.com) wrote:
> > Attached is a patch adds a --no-comments argument to pg_dump to skip
> > generation of COMMENT statements when generating a backup. This is
> crucial
> > for non-superusers to
On Sat, May 20, 2017 at 11:26 AM, Cyril Auburtin
wrote:
> Ah sorry, first time, I thought it didn't pass
>
You should check our excellent online mailing list archives before
re-sending.
https://www.postgresql.org/list/
David J.
On Sat, May 20, 2017 at 1:27 AM, Cyril Auburtin
wrote:
> It could be useful to allow the `-` char in allowed LTREE label characters
> (currently
> a-zA-Z0-9_ https://www.postgresql.org/docs/9.6/static/ltree.html)
>
> The reason is to allow to use more easily base64 ids, (like
> https://github.c
On Wed, May 17, 2017 at 12:06 AM, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> > Who is right is a judgement call, but I don't think it's self-evident
> that
> > us
On Tue, May 9, 2017 at 12:36 PM, Tom Lane wrote:
> Also, considering that this behavior has been there since 8.4,
> I think it's sheerest chutzpah to claim that changing the docs in
> v10 would materially reduce the backward-compatibility concerns
> for whatever we might do in v11.
>
No it won'
On Tue, May 9, 2017 at 12:15 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 5/5/17 08:43, David Rowley wrote:
> > How about we get the ball rolling on this in v10 and pull that part
> > out of the docs. If anything that'll buy us a bit more wiggle room to
> > change this in v
On Thu, May 4, 2017 at 9:22 AM, Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
> Yeah, the idea that this won't cause possibly significant pain is quite
> wrong. Quite by accident I came across an example just this morning where
> rewriting as a CTE makes a big improvement.
>
> I wrote
On Mon, May 1, 2017 at 7:43 AM, Andreas Karlsson wrote:
> On 05/01/2017 04:33 PM, David G. Johnston wrote:
> > On Mon, May 1, 2017 at 7:26 AM, Andreas Karlsson > I am not sure I like decorators since this means adding an ad hoc
> > query hint directly into the S
On Mon, May 1, 2017 at 7:26 AM, Andreas Karlsson wrote:
> On 05/01/2017 04:17 PM, David Fetter wrote:
>
>> Maybe we could allow a "decorator" that would tell the planner the CTE
>>> could be inlined?
>>>
>>> WITH INLINE mycte AS ( ...)
>>>
>>
>> +1 for a decorator, -1 for this one.
>>
>
> I a
On Tue, Apr 25, 2017 at 3:24 PM, David Fetter wrote:
> I don't have an exploit yet. What concerns me is attackers' access to
> what is in essence the ability to poke at RULEs when they only have
> privileges to read.
>
If they want to see how it works they can read the source code. In terms
o
On Tue, Apr 25, 2017 at 2:24 PM, Petr Jelinek
wrote:
> On 25/04/17 17:13, Fujii Masao wrote:
> > On Tue, Apr 25, 2017 at 11:34 PM, Tom Lane wrote:
> > OTOH, I believe that logical replication is still useful even without
> > initial table sync feature. So reverting the table sync patch seems
> >
On Tue, Apr 25, 2017 at 9:08 AM, Rui Hai Jiang wrote:
> When pg_basebackup is launched, a checkpoint is created first, then all
> files are transferred to the pg_basebackup client. Is it possible that a
> data page(say page-N) in a data file is changed after the checkpoint and
> before the pg_b
For reference this has been asked, and eventually answered on -general at:
https://www.postgresql.org/message-id/flat/CAKFQuwZDS7nA0SvVnumwjHBxz4CWKQm3bVNTHVeWdtAW_oXNJg%40mail.gmail.com#cakfquwzds7na0svvnumwjhbxz4cwkqm3bvnthvewdtaw_ox...@mail.gmail.com
Further comments below; partly a rehash of
On Mon, Apr 10, 2017 at 4:57 PM, Andrew Gierth
wrote:
> The distinction between the standard representation of '{}' as an array
> with zero dimensions and nonstandard representations as a 1-dimensional
> array with zero elements has come up in a couple of contexts on the IRC
> channel recently.
>
On Tue, Apr 11, 2017 at 11:10 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 4/11/17 11:47, David G. Johnston wrote:
> > A potential middle-ground is to start, but then only allow superuser
> > connections.
>
> Then you might as well start an
On Tue, Apr 11, 2017 at 8:33 AM, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 4/10/17 23:22, Tom Lane wrote:
> >> Personally I'd err on the side of "starting up degraded is better than
> >> not starting at all". Or maybe we should invent a GUC to let DBAs
> >> express their preference on t
On Mon, Apr 10, 2017 at 5:57 PM, Andrew Gierth
wrote:
> Second is aclitem[], past bug #8395 which was not really resolved; empty
> ACLs are actually 1-dim arrays of length 0, and all the ACL functions
> insist on that, which means that you can't call aclexplode('{}') for
> example:
>
> https://ww
On Fri, Apr 7, 2017 at 8:29 AM, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
> Andres, Tatsuo,
>
> Thank you for sharing your thoughts.
>
> > -1 - I frequently just override earlier parameters by adding an
> > include at the end of the file. Also, with postgresql.auto.conf it's
> > eve
On Mon, Apr 3, 2017 at 5:12 AM, Daniel Verite
wrote:
> Queries can be as complex as necessary, they just have to fit in one line.
Line continuation in general is missed though I thought something already
when in for 10.0 that improves upon this...
> In no way at all,in the sense that, eithe
On Fri, Mar 31, 2017 at 10:40 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Mar 31, 2017 at 11:29 AM, Tom Lane wrote:
> >> The argument for not back-patching a bug fix usually boils down to
> >> fear of breaking existing applications, but it's hard to see how
> >> removal of a permissio
On Wed, Mar 22, 2017 at 9:51 AM, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Wed, Mar 22, 2017 at 12:22 PM, Stephen Frost
> wrote:
> > > While I understand that you'd like to separate the concerns between
> > > changing the renaming scheme and changing
On Tue, Mar 21, 2017 at 5:12 AM, Robert Haas wrote:
>
> Here's another idea: what if we always created the default database at
> initdb time? For example, if I initdb as rhaas, maybe it should
> create an "rhaas" database for me, so that this works:
>
> initdb
> pg_ctl start
> psql
>
> I think a
On Mon, Mar 20, 2017 at 9:18 AM, Bruce Momjian wrote:
> . #3 and #4 would need to be weighted depending on
> whether choosing them would delay progress, e.g. it did delay progress
> on standard-conforming strings, but the delay was determined to be
> reasonable.
>
w.r.t. standard-conforming str
On Mon, Mar 20, 2017 at 8:57 AM, Stephen Frost wrote:
> Tom,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > * Bruce Momjian (br...@momjian.us) wrote:
> > >> 1. make the change now and mention it in the release notes
> > >> 2. #1, but also provide backward compatibil
On Sun, Mar 12, 2017 at 10:24 AM, Tom Lane wrote:
>
> One point here is that we need to distinguish problems in the expression,
> which could arise from changing variable values, from some other types of
> mistakes like \elif with no preceding \if. When you see something like
> that you pretty m
On Sat, Mar 11, 2017 at 5:45 PM, Tom Lane wrote:
>
> * Whether or not you think it's important not to expand skipped variables,
> I think that it's critical that skipped backtick expressions not be
> executed.
> [...]
> I do not think that a skipped \if or \elif
> should evaluate its argument
On Fri, Mar 10, 2017 at 3:51 PM, Alvaro Herrera
wrote:
> David G. Johnston wrote:
> > On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
>
> > is incomplete.
>
> Sure. We can just reword that along the lines of " ... and when a
&
On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera
wrote:
> David G. Johnston wrote:
> > On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
>
> > > There are several ways to cause a config file reload (pg_ctl reload,
>
On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera
wrote:
> Joshua D. Drake wrote:
>
> > I am a bad speaker, I am writing a talk three weeks before the conference
> > (as opposed to on the plane).
>
> Hah.
>
> > I noticed in the docs we still reference the
> > passing of SIGHUP for reloading conf fi
On Thu, Mar 9, 2017 at 4:45 PM, Neha Khatri wrote:
> On Fri, Mar 10, 2017 at 6:14 AM, Peter Eisentraut ndquadrant.com> wrote:
>
>> On 2/14/17 16:50, Jeff Janes wrote:
>> > make installcheck currently fails against a server running
>> > with bytea_output = escape.
>> >
>> > Making it succeed is f
On Sat, Feb 25, 2017 at 11:11 AM, Greg Stark wrote:
> On 24 February 2017 at 14:57, David G. Johnston
> wrote:
> > I dislike an error. I'd say that making partition "just work" here is
> > material for another patch. In this one an update of the partiti
On Fri, Feb 24, 2017 at 9:35 AM, David Fetter wrote:
>
> > => SELECT "?column"? FROM (select 1+1 as "?column?", 1+1) AS x;
> > ERROR: 42703: column "?column" does not exist
> > LINE 2: SELECT "?column"? FROM (select 1+1 as "?column?", 1+1) AS x;
> >^
> > HINT: Perhaps you meant
On Friday, February 24, 2017, Simon Riggs wrote:
>
> 2. I know that DB2 handles this by having the user specify WITH ROW
> MOVEMENT to explicitly indicate they accept the issue and want update
> to work even with that. We could have an explicit option to allow
> that. This appears to be the only w
On Friday, February 24, 2017, Robert Haas wrote:
> On Mon, Feb 20, 2017 at 2:58 PM, Amit Khandekar > wrote:
> > I am inclined to at least have some option for the user to decide the
> > behaviour. In the future we can even consider support for walking
> > through the ctid chain across multiple r
On Thu, Feb 23, 2017 at 6:17 PM, Amit Langote wrote:
> On 2017/02/24 8:38, Venkata B Nagothi wrote:
> > On Thu, Feb 23, 2017 at 3:14 PM, Amit Langote wrote:
> >> Upper bound of a range partition is an exclusive bound. A note was
> added
> >> recently to the CREATE TABLE page to make this clear.
On Wed, Feb 22, 2017 at 8:08 AM, Tom Lane wrote:
> Or else not generate
> a name at all, in which case there simply wouldn't be a way to refer to
> the subquery by name; I'm not sure what that might break though.
>
Yeah, usually when I want this I don't end up needing refer by name:
First I wr
On Wed, Feb 22, 2017 at 8:08 AM, Tom Lane wrote:
> Bernd Helmle writes:
> >> From time to time, especially during migration projects from Oracle to
> > PostgreSQL, i'm faced with people questioning why the alias in the FROM
> > clause for subqueries in PostgreSQL is mandatory. The default answer
On Fri, Feb 17, 2017 at 4:22 PM, Tomas Vondra
wrote:
> What about adding a paragraph into pg_basebackup docs, explaining that
> with 'fast' it does immediate checkpoint, while with 'spread' it'll wait
> for a spread checkpoint.
>
I agree that a better, and self-contained, explanation of the beha
On Wed, Feb 15, 2017 at 12:24 PM, Robert Haas wrote:
> On Tue, Jan 24, 2017 at 4:32 AM, Peter Moser wrote:
> >> Using common terms such as ALIGN and NORMALIZE for such a specific
> >> functionality seems a bit wrong.
> >
> > Would ALIGN RANGES/RANGE ALIGN and NORMALIZE RANGES/RANGE NORMALIZE be
On Thu, Feb 9, 2017 at 12:08 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Feb 6, 2017 at 12:29 PM, Magnus Hagander
> wrote:
> >>> Here is what I have, 6 votes clearly stated:
> >>> 1. Rename nothing: Daniel,
> >>> 2. Rename directory only: Andres
> >>> 3. Rename everything: Stephen, Vl
On Wed, Feb 8, 2017 at 10:30 AM, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Feb 08, 2017 at 11:22:56AM -0500, Tom Lane wrote:
> >> Yes. I think a new set-operation keyword would inevitably have to
> >> be fully reserved --- UNION, INTERSECT, and EXCEPT all are --- which
> >> means that
On Tue, Feb 7, 2017 at 8:58 AM, Tom Lane wrote:
> Joel Jacobson writes:
> > Currently there is no simple way to check if two sets are equal.
>
> Uh ... maybe check whether SELECT set1 EXCEPT SELECT set2
> and SELECT set2 EXCEPT SELECT set1 are both empty?
>
SELECT set1 FULL EXCEPT SELECT set2
On Mon, Jan 30, 2017 at 8:35 AM, Stephen Frost wrote:
> Tom,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > This particular bike-shedding really doesn't seem to be terribly useful
> > > or sensible, to me. \gx isn't "consistent" or "descriptive", frankly.
> >
> > Why
On Mon, Jan 30, 2017 at 8:14 AM, Tom Lane wrote:
> Stephen Frost writes:
> > This particular bike-shedding really doesn't seem to be terribly useful
> > or sensible, to me. \gx isn't "consistent" or "descriptive", frankly.
>
> Why not? To me it reads as "\g with an x option". The "x" refers t
On Fri, Jan 27, 2017 at 3:13 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> In any case the more idiomatic way of writing your query these days (since
> 9.4 came out) is:
>
> SELECT *
> FROM pg_constraint pc
> LEFT JOIN LATERAL generate_series(1, case whe
On Fri, Jan 27, 2017 at 5:28 AM, Rushabh Lathia
wrote:
> Consider the below test;
>
> CREATE TABLE tab ( a int primary key);
>
> SELECT *
> FROM pg_constraint pc,
> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1,
> array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position;
On Fri, Jan 27, 2017 at 8:31 AM, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > D'Arcy Cain wrote:
> >
> > > I am a pretty heavy user of psql but I don't think that that would be
> so
> > > helpful. I assume you mean a new option, let's call it "\X" the
> causes th
On Thu, Jan 26, 2017 at 4:19 PM, Andres Freund wrote:
>
> We decided s/pg_xlog/pg_wal/ was necessary because people lost their
> data, and we couldn't come up with a reasonable way to change it without
> the name. The tradeoff is dataloss vs. dealing with directory renaming
> in a few lowlevel to
On Thu, Jan 26, 2017 at 3:28 PM, Andres Freund wrote:
> I *personally* don't think it's worth
> changing all this without taking more care about backward compat than
> we're apparently willing to do. I'm ok with loosing that argument. I
> just don't think the previous concensus for a narrower c
1 - 100 of 608 matches
Mail list logo