Re: [GENERAL] PostgreSQL and Kubernetes

2017-03-31 Thread Moreno Andreo
Il 30/03/2017 14:38, Vick Khera ha scritto: On Thu, Mar 30, 2017 at 6:10 AM, Moreno Andreo wrote: Since I'm on Google Cloud Platform, I thought it would be a good

[GENERAL] Do I need to COMMIT an analyze statement?

2017-03-31 Thread Thomas Kellerer
Hello, something I have always wondered: If I run with autocommit turned OFF, do I need to commit an ANALYZE statement, or is that "non-transactional"? Thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.o

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

2017-03-31 Thread Robert Haas
On Thu, Mar 30, 2017 at 4:45 PM, Tom Lane wrote: > In short, it seems like this statement in the docs is correctly describing > our code's behavior, but said behavior is wrong and should be changed. > I'd propose fixing it like that in HEAD; I'm not sure if the back branches > should also be chang

[GENERAL] Re: Debian Bug#859033: pg_dump: creates dumps that cannot be restored

2017-03-31 Thread Thorsten Glaser
Hi *, while I’d still appreciate help on the bugreport (context is this… https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859033 … one), I’ve found this… http://dba.stackexchange.com/a/75635/65843 … which says ① that using a CHECK constraint to check data from another table is wrong (but not wh

Re: [GENERAL] Do I need to COMMIT an analyze statement?

2017-03-31 Thread David G. Johnston
On Friday, March 31, 2017, Thomas Kellerer wrote: > Hello, > > something I have always wondered: > > If I run with autocommit turned OFF, do I need to commit an ANALYZE > statement, or is that "non-transactional"? > > The results are stored in a catalog table so they are transactional. David J.

Re: [GENERAL] Re: Debian Bug#859033: pg_dump: creates dumps that cannot be restored

2017-03-31 Thread Adrian Klaver
On 03/31/2017 07:34 AM, Thorsten Glaser wrote: Hi *, while I’d still appreciate help on the bugreport (context is this… https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859033 … one), I’ve found this… http://dba.stackexchange.com/a/75635/65843 … which says ① that using a CHECK constraint to che

Re: [GENERAL] Do I need to COMMIT an analyze statement?

2017-03-31 Thread Thomas Kellerer
David G. Johnston schrieb am 31.03.2017 um 16:49: On Friday, March 31, 2017, Thomas Kellerer mailto:spam_ea...@gmx.net>> wrote: Hello, something I have always wondered: If I run with autocommit turned OFF, do I need to commit an ANALYZE statement, or is that "non-transactional"?

Re: [GENERAL] Debian Bug#859033: pg_dump: creates dumps that cannot be restored

2017-03-31 Thread Thorsten Glaser
On Fri, 31 Mar 2017, Adrian Klaver wrote: > > ① that using a CHECK constraint to check data from another table > > is wrong (but not why), and > > Because that is a documented limitation: > > https://www.postgresql.org/docs/9.6/static/sql-createtable.html > > "Currently, CHECK expressions can

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

2017-03-31 Thread Tom Lane
Robert Haas writes: > On Thu, Mar 30, 2017 at 4:45 PM, Tom Lane wrote: >> In short, it seems like this statement in the docs is correctly describing >> our code's behavior, but said behavior is wrong and should be changed. >> I'd propose fixing it like that in HEAD; I'm not sure if the back branc

Re: [GENERAL] Debian Bug#859033: pg_dump: creates dumps that cannot be restored

2017-03-31 Thread Adrian Klaver
On 03/31/2017 08:21 AM, Thorsten Glaser wrote: On Fri, 31 Mar 2017, Adrian Klaver wrote: ① that using a CHECK constraint to check data from another table is wrong (but not why), and Because that is a documented limitation: https://www.postgresql.org/docs/9.6/static/sql-createtable.html "C

Re: [GENERAL] Debian Bug#859033: pg_dump: creates dumps that cannot be restored

2017-03-31 Thread David G. Johnston
On Fri, Mar 31, 2017 at 8:21 AM, Thorsten Glaser wrote: > On Fri, 31 Mar 2017, Adrian Klaver wrote: > > > > ① that using a CHECK constraint to check data from another table > > > is wrong (but not why), and > > > > Because that is a documented limitation: > > > > https://www.postgresql.org/docs

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

2017-03-31 Thread Robert Haas
On Fri, Mar 31, 2017 at 11:29 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Mar 30, 2017 at 4:45 PM, Tom Lane wrote: >>> In short, it seems like this statement in the docs is correctly describing >>> our code's behavior, but said behavior is wrong and should be changed. >>> I'd propose fi

Re: [GENERAL] Unexpected interval comparison

2017-03-31 Thread Tom Lane
Kyotaro HORIGUCHI writes: > At Thu, 30 Mar 2017 10:57:19 -0400, Tom Lane wrote in > <2087.1490885...@sss.pgh.pa.us> >> A possible solution is to manually work in wider-than-64-bit >> arithmetic, that is compute the comparison values div and mod >> some pretty-large number and then compare the tw

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

2017-03-31 Thread Tom Lane
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 permission check could break a working application --- >> especially wh

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

2017-03-31 Thread David G. Johnston
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

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

2017-03-31 Thread Magnus Hagander
On Fri, Mar 31, 2017 at 7:40 PM, 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 permission

[GENERAL] Confusing order by error

2017-03-31 Thread
I'm hoping someone can give us a little help understanding an error in the ORDER BY clause, because when I read https://www.postgresql.org/docs/9.5/static/sql-select.html#SQL-ORDERBY I just don't see anything that explains the behavior. This is with Pg-9.5.1 on Centos (not that I think the OS m

Re: [GENERAL] Confusing order by error

2017-03-31 Thread Brian Dunavant
From the docs you linked: "Each expression can be the name or ordinal number of an output column (SELECT list item), or it can be an arbitrary expression formed from input-column values." The "name" in your order by is a reference to the output column. The following example shows the same with "

Re: [GENERAL] Confusing order by error

2017-03-31 Thread David G. Johnston
On Friday, March 31, 2017, wrote: > I'm hoping someone can give us a little help understanding an error in the > ORDER BY clause, because when I read https://www.postgresql.org/ > docs/9.5/static/sql-select.html#SQL-ORDERBY I just don't see anything > that explains the behavior. > > SELECT t1

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

2017-03-31 Thread Tom Lane
"David G. Johnston" writes: > On Fri, Mar 31, 2017 at 10:40 AM, Tom Lane wrote: >> I think the benefit is reduction of user confusion. Admittedly, since >> Paul is the first person I can remember ever having complained about it, >> maybe nobody else is confused. > ​After going back-and-forth on

Re: [GENERAL] Confusing order by error

2017-03-31 Thread
Thank you Brian and David, I'll use David's reply to refine my question... --- david.g.johns...@gmail.com wrote: > From: "David G. Johnston" > > On Friday, March 31, 2017, wrote: > > > > SELECT t1.pk, t1.name, t1.ref, CONCAT( t2.id , ':', t2.name ) AS > > ref_display > > FROM test_

Re: [GENERAL] Confusing order by error

2017-03-31 Thread David G. Johnston
On Fri, Mar 31, 2017 at 2:45 PM, wrote: > > I can go with that now that I understand it (and I did not read the docs > that way), but I guess I was expecting it to see that "upper(name)" isn't > there, so it should pull that expression apart, find "name" and see that in > the output list before i

Re: [GENERAL] Confusing order by error

2017-03-31 Thread Tom Lane
"" writes: > I can go with that now that I understand it (and I did not read the docs that > way), but I guess I was expecting it to see that "upper(name)" isn't there, > so it should pull that expression apart, find "name" and see that in the > output list before it starts searching the input

Re: [GENERAL] Confusing order by error

2017-03-31 Thread
> --- david.g.johns...@gmail.com wrote: > > On Fri, Mar 31, 2017 at 2:45 PM, wrote: > > > I can go with that now that I understand it (and I did not read the docs > > that way), but I guess I was expecting it to see that "upper(name)" isn't > > there, so it should pull that expression apart, find

Re: [GENERAL] Confusing order by error

2017-03-31 Thread
> --- t...@sss.pgh.pa.us wrote: > The short answer here is that the SQL committee changed their minds > between SQL92 and later editions of the standard, and PG is attempting > to split the difference and be reasonably compliant with both versions. > ... Thanks Tom! I'll use this as well to make