optionally schema-qualified for table_name
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t76699psql -h localhost -U postgresBuilt from patchset v2 (message #2), July 28, 2026 at 02:54 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t76699_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t76699_2 && git checkout t76699_2Patchset v2 (message #2) is on t76699_2
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.sgmlThe 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.sgmlThe 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 +