The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/sql-alterdatabase.html
Description:
The documentation of ALTER DATABASE mentions four forms and then skips to
"The remaining forms change the session default for a run-time configur
On Sun, 23 Mar 2025 at 17:31, Tom Lane wrote:
> Where do you see a pointer to CREATE SEQUENCE on that page?
Sorry, my mistake. The page only points to ALTER SEQUENCE.
Now I also see that separate section about ADD GENERATED etc,
which I completely missed earlier. I was searching fo
Rene Saarsoo writes:
> The documentation for ALTER TABLE [1] doesn't make it clear that the
> following is allowed:
> ...
> It only references the sequence options allowed in CREATE SEQUENCE or ALTER
> SEQUENCE, unlike the CREATE TABLE [2] documentation, which does
> speci
The documentation for ALTER TABLE [1] doesn't make it clear that the
following is allowed:
ALTER TABLE tbl
ALTER COLUMN id
ADD GENERATED BY DEFAULT AS IDENTITY (
SEQUENCE NAME my_name
);
It only references the sequence options allowed in CREATE SEQUENCE or ALTER
SEQUENCE, unlike the C
On Wed, Oct 16, 2024 at 05:11:54PM -0400, Bruce Momjian wrote:
> > Actually, there *is* a bug in the description, because experimentation
> > shows that CREATE DOMAIN accepts NULL in this syntax (as advertised)
> > but ALTER DOMAIN does not. We could alternatively decide that
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> How about the attached patch?
Instead of
+ Causes the possibly schema-qualified named index to become attached
I think something like
+ Causes the named index (possibly schema-qualified) to become attached
would be more readable and closer t
Hello Alvaro,
On 2024-Oct-18, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/17/sql-alterindex.html
> Description:
>
> I am trying to find out whether the syntax `ALTER INDEX name
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/sql-alterindex.html
Description:
I am trying to find out whether the syntax `ALTER INDEX name ATTACH
PARTITION index_name` accepts a schema-qualified index_name. However, there
is no
]
> > { NOT NULL | NULL | CHECK (expression) }
>
> > rather than making readers go look that up.
>
> Actually, there *is* a bug in the description, because experimentation
> shows that CREATE DOMAIN accepts NULL in this syntax (as advertised)
> but ALTER DOMAIN doe
On 11.09.24 22:12, PG Doc comments form wrote:
Page:https://www.postgresql.org/docs/16/sql-altertable.html
Description:
I am newish to Postgres, and the term "table metadata" was confusing to
me.
I think it is pretty easy to do a quick internet search to find out what
table metadata is in the
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/sql-altertable.html
Description:
I am newish to Postgres, and the term "table metadata" was confusing to
me.
I am more than happy to submit a patch for this. I'm just unfamiliar with
the
than making readers go look that up.
Actually, there *is* a bug in the description, because experimentation
shows that CREATE DOMAIN accepts NULL in this syntax (as advertised)
but ALTER DOMAIN does not. We could alternatively decide that that's
a code bug and make ALTER DOMAIN take it, b
> > { NOT NULL | NULL | CHECK (expression) }
>
> > rather than making readers go look that up.
>
Agreed
> Actually, there *is* a bug in the description, because experimentation
> shows that CREATE DOMAIN accepts NULL in this syntax (as advertised)
> but ALTER DOMAIN
readers go look that up.
Actually, there *is* a bug in the description, because experimentation
shows that CREATE DOMAIN accepts NULL in this syntax (as advertised)
but ALTER DOMAIN does not. We could alternatively decide that that's
a code bug and make ALTER DOMAIN take it, but I don't thin
"David G. Johnston" writes:
> On Monday, July 29, 2024, PG Doc comments form
> wrote:
>> In the Synopsis section of
>> https://www.postgresql.org/docs/current/sql-alterdomain.html
>> this is incorrect (incomplete):
>> "ALTER DOMAIN name ADD dom
.org/docs/current/sql-alterdomain.html
> this is incorrect (incomplete):
> "ALTER DOMAIN name ADD domain_constraint [ NOT VALID ]"
> It should be
> "ALTER DOMAIN name ADD CONSTRAINT domain_constraint [ NOT VALID ]"
>
The definition of “domain_constraint” includes the optional
On 2024-07-29 13:02 +0200, PG Doc comments form wrote:
> In the Synopsis section of
> https://www.postgresql.org/docs/current/sql-alterdomain.html
> this is incorrect (incomplete):
> "ALTER DOMAIN name ADD domain_constraint [ NOT VALID ]"
> It should be
> "
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/sql-alterdomain.html
Description:
In the Synopsis section of
https://www.postgresql.org/docs/current/sql-alterdomain.html
this is incorrect (incomplete):
"ALTER DOMAIN nam
Hello
ALTER TABLE documentation writes: "You must own the table to use ALTER TABLE.
To change the schema or tablespace of a table, you must also have CREATE
privilege on the new schema or tablespace. To add the table as a new child of a
parent table, you must own the parent table as well.
On 2024-05-23 06:04 +0200, Michael Paquier wrote:
> On Wed, May 22, 2024 at 02:12:36PM +0900, Michael Paquier wrote:
> > Will fix once we are out of release freeze time on HEAD. Thanks!
>
> And done as of dd087e1c13bf.
Thank you Michael!
--
Erik
On Wed, May 22, 2024 at 02:12:36PM +0900, Michael Paquier wrote:
> Will fix once we are out of release freeze time on HEAD. Thanks!
And done as of dd087e1c13bf.
--
Michael
signature.asc
Description: PGP signature
On Wed, May 22, 2024 at 02:59:37AM +0200, Erik Wienhold wrote:
> Here's a patch for $SUBJECT. Looks like the current wording was copied
> from ALTER TABLE. In ALTER VIEW we correctly state that column_name
> must be an existing column.
Fun. You are right, none of the patterns sup
Here's a patch for $SUBJECT. Looks like the current wording was copied
from ALTER TABLE. In ALTER VIEW we correctly state that column_name
must be an existing column.
--
Erik
>From 1d7accf2311f4fda2d8ef9a0485985620c5b4b39 Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Wed, 22 May
On 2024-04-02 16:40 +0200, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/15/sql-altertable.html
> Description:
>
> It is not entirely clear (to me) that ALTER TABLE statements with
>
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/sql-altertable.html
Description:
Hello dear PostgreSQL family,
It is not entirely clear (to me) that ALTER TABLE statements with
comma-separated sub-commands are atomic. Despite of
On Wed, 2024-01-24 at 15:26 +0100, Daniel Gustafsson wrote:
> > On 24 Jan 2024, at 15:23, Laurenz Albe wrote:
> >
> > On Wed, 2024-01-24 at 11:08 +0100, gp...@free.fr wrote:
> > > for this "ALTER DATABASE" form, it should be mentioned that after
> >
Thank you for the feedback. I've taken it into account and come up with a
partial rewrite of my first pass, and posted it to -hackers so we can close
this thread out.
https://www.postgresql.org/message-id/cakfquwyy3ei05kpggk2del_pe5yjkdybxb362xuthovpqjf...@mail.gmail.com
Some replies below.
On
gml/ddl.sgml
> index fc03a349f0..c8866ee9c7 100644
> --- a/doc/src/sgml/ddl.sgml
> +++ b/doc/src/sgml/ddl.sgml
> @@ -1856,15 +1856,12 @@ ALTER TABLE products RENAME TO items;
>
>
> When an object is created, it is assigned an owner. The
> - owner is normally the role tha
On Wed, Jan 24, 2024 at 7:23 AM Laurenz Albe
wrote:
> On Wed, 2024-01-24 at 11:08 +0100, gp...@free.fr wrote:
> > for this "ALTER DATABASE" form, it should be mentioned that after
> execution of the command,
> > the old database owner loses all his privileges on it
afsson"
, "pgsql-docs"
Envoyé: Mercredi 24 Janvier 2024 18:11:30
Objet: Re: SQL command : ALTER DATABASE OWNER TO
De: "David G. Johnston"
À: "gparc"
Cc: "Laurenz Albe" , "Daniel Gustafsson"
, "pgsql-docs"
Envoyé: Mercred
pe | en_US.UTF-8
ICU Locale|
ICU Rules |
Access privileges | testowner=CTc/testowner+
| to3=C*T*c*/testowner +
| to4=CTc/to3+
| testowner=CTc/to3
postgres=> reset role;
RESET
postgres=#
"David G. Johnston" writes:
> postgres=# grant all on database newdb2 to testowner;
> -- as I am logged in as davidj this grant should actually happen, with
> davidj as the grantor
> -- the grants that materialize from ownership has the owning role as the
> grantor
Yes. The FM points out somewhe
De: "David G. Johnston"
À: "gparc"
Cc: "Laurenz Albe" , "Daniel Gustafsson"
, "pgsql-docs"
Envoyé: Mercredi 24 Janvier 2024 17:50:17
Objet: Re: SQL command : ALTER DATABASE OWNER TO
On Wed, Jan 24, 2024 at 9:23 AM < [ mailto:gp.
ase any more).
> I dislike this change, ownership of an object is completely independent of
> the grant system of privileges. The granted privileges of the old row do
> not transfer to the new owner when alter ... owner to is executed. The
> separate object attribute "owner" is
On Wed, Jan 24, 2024 at 9:56 AM Alvaro Herrera
wrote:
> On 2024-Jan-24, Laurenz Albe wrote:
>
> > The permissions are transferred to the new owner, so the old owner
> doesn't
> > have any privileges on the object (and, in your case, cannot connect to
> > the database any more).
>
> However, if th
On 2024-Jan-24, Laurenz Albe wrote:
> The permissions are transferred to the new owner, so the old owner doesn't
> have any privileges on the object (and, in your case, cannot connect to
> the database any more).
However, if the old owner had a pg_hba.conf line that allowed them in,
and the new o
On Wed, Jan 24, 2024 at 9:23 AM wrote:-
> [postgres] $ psql
> psql (14.10)
>
>
You really should add commentary, especially since you never demonstrated
the tst role (I advise picking different names for all of the objects in
the future) being unable to login. Which they should be able to since
De: "David G. Johnston"
À: "Laurenz Albe"
Cc: "gparc" , "Daniel Gustafsson" ,
"pgsql-docs"
Envoyé: Mercredi 24 Janvier 2024 17:36:43
Objet: Re: SQL command : ALTER DATABASE OWNER TO
On Wed, Jan 24, 2024 at 9:13 AM Laurenz Alb
> not transfer to the new owner when alter ... owner to is executed.
>
> CREATE TABLE mytab ();
>
> REVOKE ALL ON mytab FROM PUBLIC;
>
> \z mytab
> Access privileges
> Schema │ Name │ Type │ Access
- Mail original -
De: "Laurenz Albe"
À: "gparc" , "Daniel Gustafsson"
Cc: "pgsql-docs"
Envoyé: Mercredi 24 Janvier 2024 16:35:10
Objet: Re: SQL command : ALTER DATABASE OWNER TO
On Wed, 2024-01-24 at 15:40 +0100, gp...@free.fr wrote:
> ma
On Wed, 2024-01-24 at 08:47 -0700, David G. Johnston wrote:
> I dislike this change, ownership of an object is completely independent of
> the grant system of privileges. The granted privileges of the old row do
> not transfer to the new owner when alter ... owner to is executed.
CRE
t connect to
> the database any more).
>
>
I dislike this change, ownership of an object is completely independent of
the grant system of privileges. The granted privileges of the old row do
not transfer to the new owner when alter ... owner to is executed. The
separate object attribute &quo
On Wed, 2024-01-24 at 15:40 +0100, gp...@free.fr wrote:
> maybe a misunderstanding of my part, but your proposed modification doesn't
> matched
> with the current behaviour of the command as precisely the object privileges
> of the old owner are **NOT** transferred
> to the new owner along with t
The ALTER EVENT TRIGGER .. page has an extra TRIGGER in the parameters section
for ENABLE/DISABLE parameters which isn't supported in the grammar:
https://www.postgresql.org/docs/devel/sql-altereventtrigger.html
postgres=# alter event trigger on_login_trigger disable trigger;
ginal -
De: "Daniel Gustafsson"
À: "Laurenz Albe"
Cc: "gparc" , "pgsql-docs"
Envoyé: Mercredi 24 Janvier 2024 15:26:22
Objet: Re: SQL command : ALTER DATABASE OWNER TO
> On 24 Jan 2024, at 15:23, Laurenz Albe wrote:
>
> On Wed, 2024-01-24 a
> On 24 Jan 2024, at 15:23, Laurenz Albe wrote:
>
> On Wed, 2024-01-24 at 11:08 +0100, gp...@free.fr wrote:
>> for this "ALTER DATABASE" form, it should be mentioned that after execution
>> of the command,
>> the old database owner loses all his privileges
On Wed, 2024-01-24 at 11:08 +0100, gp...@free.fr wrote:
> for this "ALTER DATABASE" form, it should be mentioned that after execution
> of the command,
> the old database owner loses all his privileges on it (even connection)
> although it might
> still owns schemas
Hello,
as one of my colleagues fell into the same trap
I repeat my request for correction of the documentation on this subject.
Many thanks in advance
Regards
Gilles
- Mail original -
De: "gparc"
À: "pgsql-docs"
Envoyé: Mardi 8 Mars 2022 10:50:38
Objet: SQL comm
On Wed, Aug 26, 2015 at 07:31:53PM -0400, Josh Kupershmidt wrote:
> I'd like to propose the following slight rewording for the note about ALTER
> TABLE ... ADD table_constraint_using_index. The existing text says one may
> "install it [the existing index] as an official co
On Thu, Feb 22, 2018 at 07:50:19PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page:
> https://www.postgresql.org/docs/10/static/sql-alterdefaultprivileges.html
> Description:
>
> The documentation of ALT
On Fri, 2023-11-03 at 09:53 -0400, Bruce Momjian wrote:
> On Thu, Nov 2, 2023 at 09:51:58PM -0400, Bruce Momjian wrote:
> > On Wed, Nov 1, 2023 at 09:31:52PM +0100, Laurenz Albe wrote:
> > > There is another patch in the current commitfest that addresses a similar
> > > problem, triggered by anot
On Thu, Nov 2, 2023 at 09:51:58PM -0400, Bruce Momjian wrote:
> On Wed, Nov 1, 2023 at 09:31:52PM +0100, Laurenz Albe wrote:
> > There is another patch in the current commitfest that addresses a similar
> > problem, triggered by another complaint:
> > https://commitfest.postgresql.org/45/4633/
>
On Wed, Nov 1, 2023 at 09:31:52PM +0100, Laurenz Albe wrote:
> On Wed, 2023-11-01 at 13:09 -0400, Bruce Momjian wrote:
> > On Thu, Feb 18, 2021 at 08:16:13AM +0100, Laurenz Albe wrote:
> > > On Wed, 2021-02-17 at 15:08 -0500, Jordi Gutiérrez Hermoso wrote:
> > > > I just had a confusing moment try
On Wed, 2023-11-01 at 13:09 -0400, Bruce Momjian wrote:
> On Thu, Feb 18, 2021 at 08:16:13AM +0100, Laurenz Albe wrote:
> > On Wed, 2021-02-17 at 15:08 -0500, Jordi Gutiérrez Hermoso wrote:
> > > I just had a confusing moment trying to figure out why my roles
> > > weren't creating tables the way I
urrent role is a member.
- If FOR ROLE is omitted, the current role is assumed.
+ Default access privileges are not inherited, so member roles
+ must use SET ROLE to access these privileges,
+ or ALTER DEFAULT PRIVILEGES must be run for
+ each member role. If FOR ROLE is omitted,
+ the current role is assumed.
On Tue, Oct 24, 2023 at 02:36:14PM -0400, Bruce Momjian wrote:
> On Tue, Oct 24, 2023 at 02:05:53PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I have developed the attached patch to document this.
> >
> > This seems a little imprecise:
> >
> > + Values with non-alphanumeric char
stem.sgml
index 6f8bd39eaf..bea5714ba1 100644
--- a/doc/src/sgml/ref/alter_system.sgml
+++ b/doc/src/sgml/ref/alter_system.sgml
@@ -21,7 +21,7 @@ PostgreSQL documentation
-ALTER SYSTEM SET configuration_parameter { TO | = } { value | 'value' | DEFAULT }
+ALTER SYSTEM SET configuration
Bruce Momjian writes:
> I have developed the attached patch to document this.
This seems a little imprecise:
+ Values with non-alphanumeric characters must be quoted.
I think accurate is more like "Values that are neither a number
nor a valid identifier must be quoted."
Also, that para al
standby_names
wal_consistency_checking
debug_io_direct
and this leads to different quoting behaviors depending on which
category of list you are using. First, let's look at alphanumeric
values, which are treated the same by list types with different
GUC_LIST_Q
On Mon, 2023-10-16 at 16:21 -0400, Tom Lane wrote:
> So maybe we should allow ALTER SYSTEM for unrecognized parameters,
> as long as the parameter name is syntactically legit and you're a
> superuser.
That seems more consistent than the current behavior, so +1.
Yours,
Laurenz Albe
Laurenz Albe writes:
> On Mon, 2023-10-16 at 12:29 -0400, Tom Lane wrote:
>> So that feels like a bug: we should not allow ALTER SYSTEM to execute
>> against a placeholder GUC definition, because the placeholder can't
>> tell us whether the value is valid. I wonder th
On Mon, 2023-10-16 at 12:29 -0400, Tom Lane wrote:
> I do see an issue here:
>
> regression=# ALTER SYSTEM SET foo.bar TO 'baz';
> ERROR: unrecognized configuration parameter "foo.bar"
> regression=# SET foo.bar TO 'baz';
> SET
> regression=
PG Doc comments form writes:
> As far as I can tell, the following statement:
>> PostgreSQL will accept a setting for any two-part parameter name
> does not hold when creating a *new* setting with `ALTER SYSTEM`, e.g.
> ALTER SYSTEM SET foo.bar TO 'baz';
>
g a *new* setting with `ALTER SYSTEM`, e.g.
ALTER SYSTEM SET foo.bar TO 'baz';
will elicit an error.
However, if `foo.bar` is defined in `postgresql.conf` or
`postgresql.auto.conf` – put there by hand – then it can be altered, i.e.
the `ALTER SYSTEM` command above will succeed.
I don&#
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/sql-alterpolicy.html
Description:
Hi folks, just wanted to drop a documentation suggestion: we document that
e.g. ALTER TABLE acquires an ACCESS EXCLUSIVE lock most of the time, but
On Sun, Aug 20, 2023 at 8:56 AM PG Doc comments form
wrote:
> When the folloing SQL is executed:
> ALTER TABLE "table" ALTER COLUMN "id" SET RESTART WITH nnn raises error
> then an error is returned:
>
Yes, because if you take the RESTART branch in the synta
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/sql-altertable.html
Description:
Hi,
When the folloing SQL is executed:
ALTER TABLE "table" ALTER COLUMN "id" SET RESTART WITH nnn raises error
then an error
"Jonathan S. Katz" writes:
> On 12/15/22 10:50 AM, David G. Johnston wrote:
>> I suggest changing it to:
>> SET configuration_parameter { TO | = } { value [, ...] | DEFAULT }
> +1 in general. I would also suggest we add an example in the Examples
> section to show what the output is when you add
<https://www.postgresql.org/docs/15/sql-altersystem.html>
Description:
Documentation say
ALTER SYSTEM SET configuration_parameter { TO | = } { value | 'value' |
DEFAULT }
The variant 'value' has special, not obvious behaviour and must be
documented.
On Thu, Dec 15, 2022 at 4:45 AM PG Doc comments form
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/15/sql-altersystem.html
> Description:
>
> Documentation say
> ALTER SYSTEM SET configuration_paramet
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/sql-altersystem.html
Description:
Documentation say
ALTER SYSTEM SET configuration_parameter { TO | = } { value | 'value' |
DEFAULT }
The variant 'value' has
PG Doc comments form writes:
> I think there's a mistake under "and table_constraint is:" where the
> different constraints are listed.
> Here: https://www.postgresql.org/docs/current/sql-altertable.html
> The definition here allows for CHECK constraints to be deferrable when they
> are not.
It'
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/sql-altertable.html
Description:
I think there's a mistake under "and table_constraint is:" where the
different constraints are listed.
Here: https://www.postgresql.org/docs/current/sql-al
ersions 14/15 documentation would be
> > helpful specifically
> > surrounding the "target_role" clause for the ALTER DEFAULT PRIVILEGES
> > command.
> > To the uninitiated, the current description seems vague. Maybe something
> > like the following would hel
rget_role" clause for the ALTER DEFAULT PRIVILEGES command.
> To the uninitiated, the current description seems vague. Maybe something
> like the following would help:
>
> target_role
> The name of an existing role of which the current role is a member.
>
To Whom It May Concern;
Some additional clarity in the versions 14/15 documentation would be helpful
specifically surrounding the "target_role" clause for the ALTER DEFAULT
PRIVILEGES command. To the uninitiated, the current description seems vague.
Maybe something like the follo
Hi Leslie,
On Sat, Mar 05, 2022 at 10:15:33AM +, PG Doc comments form wrote:
> "ALTER ROUTINE" and "DROP ROUTINE" are not listed in the "Event Trigger
> Firing Matrix" documentation page, even though these tags seem supported
> from PostgreSQL 11 onw
On Tue, Mar 8, 2022 at 7:39 AM Bruce Momjian wrote:
> On Tue, Mar 8, 2022 at 10:50:38AM +0100, gp...@free.fr wrote:
> >
> > Hello,
> >
> > for this "ALTER DATABASE" form, it should be mentioned that after
> execution of the command,
> > the old
On Tue, Mar 8, 2022 at 10:50:38AM +0100, gp...@free.fr wrote:
>
> Hello,
>
> for this "ALTER DATABASE" form, it should be mentioned that after execution
> of the command,
> the old database owner loses all his privileges on it (even connection)
> although i
Hello,
for this "ALTER DATABASE" form, it should be mentioned that after execution of
the command,
the old database owner loses all his privileges on it (even connection)
although it might
still owns schemas or objects (tables, index,...) inside it.
Thanks in advance to add this
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/14/event-trigger-matrix.html
Description:
Hi,
"ALTER ROUTINE" and "DROP ROUTINE" are not listed in the "Event Trigger
Firing Matrix" documentation pag
On 2021-Oct-26, nikolai.berkoff wrote:
> Thank you, this reads better.
> Is there a reason in the docs there is sometimes
>
> ANALYZE
>
> and sometimes only
>
> ANALYZE
> ? I prefer the link if there is no hard rule.
I pushed this on November 5th; it is commit
df80f9da5c6541e744eeb20eac
‐‐‐ Original Message ‐‐‐
On Tuesday, October 19th, 2021 at 16:16, Alvaro Herrera
wrote:
> I would put it in a separate one instead, as in the attached.
Thank you, this reads better.
Is there a reason in the docs there is sometimes
ANALYZE
and sometimes only
ANALYZE
? I prefer
> However, it does not belong to the description. I would add it to the
> > > Notes
> > > section at the end of the ALTER TABLE page.
> >
> > No objections to the suggested addition and the location of the
> > addition (paragraph of SET DATA TYPE rather
On Tue, Oct 19, 2021 at 12:16:44PM -0300, Alvaro Herrera wrote:
> Dunno, putting it in the middle of the existing paragraph looks odd to
> me. I would put it in a separate one instead, as in the attached.
Fine by me. Thanks!
--
Michael
signature.asc
Description: PGP signature
ion at the end of the ALTER TABLE page.
>
> No objections to the suggested addition and the location of the
> addition (paragraph of SET DATA TYPE rather than "Notes"), but I think
> that the phrasing could be better:
> "The column's statistics are removed, hence a f
On Mon, Oct 18, 2021 at 05:15:59PM -0300, Euler Taveira wrote:
> I agree that it might surprise an user and it would be good to document it.
> However, it does not belong to the description. I would add it to the Notes
> section at the end of the ALTER TABLE page.
No objections to the
good to document it.
However, it does not belong to the description. I would add it to the Notes
section at the end of the ALTER TABLE page.
--
Euler Taveira
EDB https://www.enterprisedb.com/
The current documentation does not mention that the column statistics are
removed which I can see they are in src/backend/commands/tablecmds.c
ATExecAlterColumnType
/*
* Drop any pg_statistic entry for the column, since it's now wrong type
*/
RemoveStatistics(Rel
> I don't follow why you put this documentation under ALTER TABLE ... DROP
> EXPRESSION. That action doesn't seem related to what you were hoping to do.
I thought that's where it would be if we had ADD/SET EXPRESSION
statements, just like the ADD/SET GENERATED statements just below.
On 30.05.21 15:25, Emre Hasegeli wrote:
I was trying to change the generation expression of a generated stored
column using ALTER TABLE. It took me a while before I figured SET
GENERATED applies only to generated identity columns. I think it'd be
useful to note this in the documentation
On Sun, 2021-05-30 at 16:25 +0300, Emre Hasegeli wrote:
> I was trying to change the generation expression of a generated stored
> column using ALTER TABLE. It took me a while before I figured SET
> GENERATED applies only to generated identity columns. I think it'd be
> usefu
I was trying to change the generation expression of a generated stored
column using ALTER TABLE. It took me a while before I figured SET
GENERATED applies only to generated identity columns. I think it'd be
useful to note this in the documentation with something like the
attached.
000
dated ICU
collations. Like this:
DO $BODY$
DECLARE
r RECORD;
BEGIN
FOR r IN (
SELECT n.nspname, c.collname
FROM pg_collation c JOIN pg_namespace n ON c.collnamespace =
n.oid
WHERE c.collversion <> pg_collation_actual_version(c.oid)
) LOOP
EXECU
On Sunday, April 25, 2021, PG Doc comments form
wrote:
>
> I use postgresql 12.6. I want to restart my sequence something like that:
> alter sequence quiz_seq restart with ((select max(id) from quiz)+1);
> but I can't do it. Please, clarify. Can I use only plain numbers li
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/sql-altersequence.html
Description:
Hi!
I have some question about alter sequence. I can see in your documentation
https://www.postgresql.org/docs/12/sql-altersequence.html Synopsis
I cannot count the number of times I have seen people confused by that.
Suggested patch attached.
Yours,
Laurenz Albe
From 6ca7ad89b06c65d574a5e9da8192a14458863cb6 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 18 Feb 2021 08:14:55 +0100
Subject: [PATCH] Clarify docs for ALTER DEFAULT PRI
I just had a confusing moment trying to figure out why my roles
weren't creating tables the way I was expecting them to. I didn't
understand what the `target_role` parameter did. No matter how I try
to read this page, I can't see an explanation for that parameter:
https://www.postgresql.org/docs/c
> Maybe it'd help to split the GRANT and REVOKE cases completely,
> along the lines of
> ALTER DEFAULT PRIVILEGES
> [ FOR { ROLE | USER } target_role [, ...] ]
> [ IN SCHEMA schema_name [, ...] ]
> GRANT privilege_and_object_type
> TO { [
PG Doc comments form writes:
> The syntax/synopsis of the "ALTER DEFAULT PRIVILEGES" statement on the
> https://www.postgresql.org/docs/13/sql-alterdefaultprivileges.html page can
> be simplified to the below form:
> [ factor out privileges and object type ]
Hmm. I can&#
1 - 100 of 131 matches
Mail list logo
