Thread

Commits

  1. psql: Fix logging output format

  2. Fix incorrect CREATE STATISTICS example in docs

  1. CREATE STATISTICS documentation bug

    Robert Haas <robertmhaas@gmail.com> — 2019-06-14T19:23:29Z

    https://www.postgresql.org/docs/12/sql-createstatistics.html contains
    this example command:
    
    CREATE STATISTICS s2 (mcv) ON (a, b) FROM t2;
    
    But that produces:
    
    psql: ERROR:  only simple column references are allowed in CREATE STATISTICS
    
    I think the parentheses around (a, b) just need to be removed.
    
    P.S. I think the fact that we print "psql: " before the ERROR here is
    useless clutter.  We didn't do that in v11 and prior and I think we
    should kill it with fire.
    
    -- 
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
    
    
    
    
  2. Re: CREATE STATISTICS documentation bug

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-06-14T19:26:01Z

    Robert Haas <robertmhaas@gmail.com> writes:
    > P.S. I think the fact that we print "psql: " before the ERROR here is
    > useless clutter.  We didn't do that in v11 and prior and I think we
    > should kill it with fire.
    
    Agreed, particularly seeing that the error is not originating with
    psql; it's just passing it on.
    
    			regards, tom lane
    
    
    
    
  3. Re: CREATE STATISTICS documentation bug

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2019-06-14T20:25:07Z

    On 2019-Jun-14, Tom Lane wrote:
    
    > Robert Haas <robertmhaas@gmail.com> writes:
    > > P.S. I think the fact that we print "psql: " before the ERROR here is
    > > useless clutter.  We didn't do that in v11 and prior and I think we
    > > should kill it with fire.
    > 
    > Agreed, particularly seeing that the error is not originating with
    > psql; it's just passing it on.
    
    +1
    
    Proposal: each program declares at startup whether it wants the program
    name prefix or not.
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
    
  4. Re: CREATE STATISTICS documentation bug

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-06-14T20:48:35Z

    Alvaro Herrera <alvherre@2ndquadrant.com> writes:
    > On 2019-Jun-14, Tom Lane wrote:
    >> Robert Haas <robertmhaas@gmail.com> writes:
    >>> P.S. I think the fact that we print "psql: " before the ERROR here is
    >>> useless clutter.  We didn't do that in v11 and prior and I think we
    >>> should kill it with fire.
    
    >> Agreed, particularly seeing that the error is not originating with
    >> psql; it's just passing it on.
    
    > +1
    
    > Proposal: each program declares at startup whether it wants the program
    > name prefix or not.
    
    Well, to clarify: I think it's reasonable to include "psql: " if the
    message is originating in psql.  So I don't think your idea quite
    does what we want.
    
    			regards, tom lane
    
    
    
    
  5. Re: CREATE STATISTICS documentation bug

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2019-06-14T21:04:14Z

    On 2019-Jun-14, Tom Lane wrote:
    
    > Alvaro Herrera <alvherre@2ndquadrant.com> writes:
    
    > > Proposal: each program declares at startup whether it wants the program
    > > name prefix or not.
    > 
    > Well, to clarify: I think it's reasonable to include "psql: " if the
    > message is originating in psql.  So I don't think your idea quite
    > does what we want.
    
    Hmm, it doesn't.
    
    Maybe the error reporting API needs a bit of a refinement to suppress
    the prefix for specific error callsites, then?
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
    
  6. Re: CREATE STATISTICS documentation bug

    Tomas Vondra <tomas.vondra@2ndquadrant.com> — 2019-06-15T23:22:19Z

    On Fri, Jun 14, 2019 at 03:23:29PM -0400, Robert Haas wrote:
    >https://www.postgresql.org/docs/12/sql-createstatistics.html contains
    >this example command:
    >
    >CREATE STATISTICS s2 (mcv) ON (a, b) FROM t2;
    >
    >But that produces:
    >
    >psql: ERROR:  only simple column references are allowed in CREATE STATISTICS
    >
    >I think the parentheses around (a, b) just need to be removed.
    >
    >P.S. I think the fact that we print "psql: " before the ERROR here is
    >useless clutter.  We didn't do that in v11 and prior and I think we
    >should kill it with fire.
    >
    
    I've pushed a fix for the docs issue.
    
    -- 
    Tomas Vondra                  http://www.2ndQuadrant.com
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 
    
    
    
    
  7. Re: CREATE STATISTICS documentation bug

    Robert Haas <robertmhaas@gmail.com> — 2019-06-17T12:01:06Z

    On Sat, Jun 15, 2019 at 7:22 PM Tomas Vondra
    <tomas.vondra@2ndquadrant.com> wrote:
    > I've pushed a fix for the docs issue.
    
    Thanks.
    
    -- 
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
    
    
    
    
  8. Re: CREATE STATISTICS documentation bug

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2019-07-06T20:59:20Z

    On 2019-06-14 23:04, Alvaro Herrera wrote:
    > On 2019-Jun-14, Tom Lane wrote:
    > 
    >> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
    > 
    >>> Proposal: each program declares at startup whether it wants the program
    >>> name prefix or not.
    >>
    >> Well, to clarify: I think it's reasonable to include "psql: " if the
    >> message is originating in psql.  So I don't think your idea quite
    >> does what we want.
    > 
    > Hmm, it doesn't.
    > 
    > Maybe the error reporting API needs a bit of a refinement to suppress
    > the prefix for specific error callsites, then?
    
    This was an oversight and has been fixed.  (It was masked if you had a
    .psqlrc, which is why I never saw it.)
    
    -- 
    Peter Eisentraut              http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services