Обсуждение: optionally schema-qualified for table_name

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/12/sql-altersequence.html
Description:

Although I can see that table_name in OWNED BY clause can be optionally
schema-qualified by ᅟcarefully reading "The specified table must have the
same owner and be in the same schema as the sequence.", it would be good if
"optionally schema-qualified" is explicitly noted somehow like other pages
such as CREATE TABLE and CREATE VIEW. The same applies to CREATE SEQUENCE
page.

On Thu, Mar 12, 2020 at 05:58:02AM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/12/sql-altersequence.html
> Description:
> 
> Although I can see that table_name in OWNED BY clause can be optionally
> schema-qualified by ᅟcarefully reading "The specified table must have the
> same owner and be in the same schema as the sequence.", it would be good if
> "optionally schema-qualified" is explicitly noted somehow like other pages
> such as CREATE TABLE and CREATE VIEW. The same applies to CREATE SEQUENCE
> page.

I see what you mean.  The attached patch fixes this, as well as
adjusting the error message.  I didn't see any other cases.

I thought maybe the schema wasn't mentioned because the table.column
defaults to the sequence's schema, but it does not --- you have to
specify the column's schema if would not be normally be found via
search_path:

    CREATE SCHEMA zz;
    
    SET search_path = zz, public;
    
    CREATE TABLE zz.test (x INT);
    CREATE SEQUENCE zz.ss;
    
    ALTER SEQUENCE zz.ss OWNED BY test.x;
    
    SET search_path = public, zz;
    ALTER SEQUENCE zz.ss OWNED BY test.x;
    
    SET search_path = public;

    ALTER SEQUENCE zz.ss OWNED BY test.x;
-->    ERROR:  relation "test" does not exist
    ALTER SEQUENCE zz.ss OWNED BY zz.test.x;

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Bruce Momjian <bruce@momjian.us> writes:
> I see what you mean.  The attached patch fixes this, as well as
> adjusting the error message.  I didn't see any other cases.

I don't really think this is an improvement, mainly because that
error message is inventing a notation that we do not use in any
other error message.

            regards, tom lane

On Sun, Mar 22, 2020 at 03:05:01PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I see what you mean.  The attached patch fixes this, as well as
> > adjusting the error message.  I didn't see any other cases.
> 
> I don't really think this is an improvement, mainly because that
> error message is inventing a notation that we do not use in any
> other error message.

What do you suggest?  The current message is:

    Specify OWNED BY table.column or OWNED BY NONE.

I don't see any other messages with "table.column".  Do you want?

    Specify OWNED BY column or OWNED BY NONE.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Bruce Momjian <bruce@momjian.us> writes:
> On Sun, Mar 22, 2020 at 03:05:01PM -0400, Tom Lane wrote:
>> I don't really think this is an improvement, mainly because that
>> error message is inventing a notation that we do not use in any
>> other error message.

> What do you suggest?  The current message is:

>     Specify OWNED BY table.column or OWNED BY NONE.

Yeah, and I think that's okay as-is, or at least we can't make it better
without fairly whole-sale changes of our documentation practices.
The fact that a table name can be schema-qualified is usually implicit,
and I don't see why this place cries out for making it explicit
more than other places.  You could as well complain that there's
nothing explicit here about double-quoting practices.

            regards, tom lane

On Sun, Mar 22, 2020 at 06:20:04PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Sun, Mar 22, 2020 at 03:05:01PM -0400, Tom Lane wrote:
> >> I don't really think this is an improvement, mainly because that
> >> error message is inventing a notation that we do not use in any
> >> other error message.
> 
> > What do you suggest?  The current message is:
> 
> >     Specify OWNED BY table.column or OWNED BY NONE.
> 
> Yeah, and I think that's okay as-is, or at least we can't make it better
> without fairly whole-sale changes of our documentation practices.
> The fact that a table name can be schema-qualified is usually implicit,
> and I don't see why this place cries out for making it explicit
> more than other places.  You could as well complain that there's
> nothing explicit here about double-quoting practices.

OK, I will do just the documentation patch for this then.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On 2020-03-23 02:27, Bruce Momjian wrote:
> On Sun, Mar 22, 2020 at 06:20:04PM -0400, Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> On Sun, Mar 22, 2020 at 03:05:01PM -0400, Tom Lane wrote:
>>>> I don't really think this is an improvement, mainly because that
>>>> error message is inventing a notation that we do not use in any
>>>> other error message.
>>
>>> What do you suggest?  The current message is:
>>
>>>     Specify OWNED BY table.column or OWNED BY NONE.
>>
>> Yeah, and I think that's okay as-is, or at least we can't make it better
>> without fairly whole-sale changes of our documentation practices.
>> The fact that a table name can be schema-qualified is usually implicit,
>> and I don't see why this place cries out for making it explicit
>> more than other places.  You could as well complain that there's
>> nothing explicit here about double-quoting practices.
> 
> OK, I will do just the documentation patch for this then.

The same criticism applies to the documentation patch, I think.  We 
don't usually make the schema part explicit.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Mar 24, 2020 at 09:35:25PM +0100, Peter Eisentraut wrote:
> On 2020-03-23 02:27, Bruce Momjian wrote:
> > On Sun, Mar 22, 2020 at 06:20:04PM -0400, Tom Lane wrote:
> > > Bruce Momjian <bruce@momjian.us> writes:
> > > > On Sun, Mar 22, 2020 at 03:05:01PM -0400, Tom Lane wrote:
> > > > > I don't really think this is an improvement, mainly because that
> > > > > error message is inventing a notation that we do not use in any
> > > > > other error message.
> > > 
> > > > What do you suggest?  The current message is:
> > > 
> > > >     Specify OWNED BY table.column or OWNED BY NONE.
> > > 
> > > Yeah, and I think that's okay as-is, or at least we can't make it better
> > > without fairly whole-sale changes of our documentation practices.
> > > The fact that a table name can be schema-qualified is usually implicit,
> > > and I don't see why this place cries out for making it explicit
> > > more than other places.  You could as well complain that there's
> > > nothing explicit here about double-quoting practices.
> > 
> > OK, I will do just the documentation patch for this then.
> 
> The same criticism applies to the documentation patch, I think.  We don't
> usually make the schema part explicit.

That is a good point. I used CREATE VIEW as an example because that is
what the user reported, but it seems only create_view and reindexed use
a schema name qualification:

    $ grep  -l '<replaceable>schema</replaceable>' *.sgml
    create_view.sgml
    reindexdb.sgml

The reindexdb use is because of -S (reindex schema), which makes sense. 
The create view case is used in an example of CREATE RECURSIVE VIEW and
should probably be removed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On 2020-03-24 21:58, Bruce Momjian wrote:
> That is a good point. I used CREATE VIEW as an example because that is
> what the user reported, but it seems only create_view and reindexed use
> a schema name qualification:
> 
>     $ grep  -l '<replaceable>schema</replaceable>' *.sgml
>     create_view.sgml
>     reindexdb.sgml
> 
> The reindexdb use is because of -S (reindex schema), which makes sense.
> The create view case is used in an example of CREATE RECURSIVE VIEW and
> should probably be removed.

The CREATE RECURSIVE VIEW example is making a specific point about 
schema qualification, which is explained below the example.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Wed, Mar 25, 2020 at 01:46:54PM +0100, Peter Eisentraut wrote:
> On 2020-03-24 21:58, Bruce Momjian wrote:
> > That is a good point. I used CREATE VIEW as an example because that is
> > what the user reported, but it seems only create_view and reindexed use
> > a schema name qualification:
> > 
> >     $ grep  -l '<replaceable>schema</replaceable>' *.sgml
> >     create_view.sgml
> >     reindexdb.sgml
> > 
> > The reindexdb use is because of -S (reindex schema), which makes sense.
> > The create view case is used in an example of CREATE RECURSIVE VIEW and
> > should probably be removed.
> 
> The CREATE RECURSIVE VIEW example is making a specific point about schema
> qualification, which is explained below the example.

OK, so I guess everything is fine and we can just go back to other
business.  :-)   Sorry for the distraction.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +