Fwd: PostgreSQL 12 Authentication type questions
> Hello Postgresql Team, > > I have a question for you. > > If we would like to implement ldap authentication as well as password > authentication for some users at a same time (like authentication type as > password, global in oracle), Is there any option with postgresql 12? I did > tested password authentication and as well as ldap authentication users > separately by touching pg_hba.conf file, it works separately but not at the > same time for different users.. But If i want to use two different users , > one user with ldap authentication and another user with password > authentication like in Oracle. Is it possible ? Please advise. > > Also please confirm same user with mixed mode authentication like in > Microsoft SQL server(same user with authentication type which is password > as well as ldap), Is it possible? > > Is it bug or there is a workaround? Please confirm. > > Appreciate your quick response. > > You can contact me @+919500114519 or +13132026377 > > Regards, > Anitha P. >
ALTER TABLE ... SET DATA TYPE removes statistics
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(RelationGetRelid(rel), attnum); Although this might be obvious it tripped me up. For example renaming and SET STATISTICS preserves statistics. Patch attached. Regards, Nikolaidiff --git i/doc/src/sgml/ref/alter_table.sgml w/doc/src/sgml/ref/alter_table.sgml index 8129157..ef59db0 100644 --- i/doc/src/sgml/ref/alter_table.sgml +++ w/doc/src/sgml/ref/alter_table.sgml @@ -187,7 +187,8 @@ WITH ( MODULUS numeric_literal, REM This form changes the type of a column of a table. Indexes and simple table constraints involving the column will be automatically converted to use the new column type by reparsing the originally - supplied expression. + supplied expression. Note this will remove the column's statistics + so will normally be followed by an ANALYZE of the table. The optional COLLATE clause specifies a collation for the new column; if omitted, the collation is the default for the new column type. signature.asc Description: OpenPGP digital signature
vacuumdb --analyze-in-stages
Running --analyze-in-stages on a database with statistics causes the statistics to become significantly worse before they are improved. This could be made clearer in the documentation.diff --git i/doc/src/sgml/ref/vacuumdb.sgml w/doc/src/sgml/ref/vacuumdb.sgml index 223b986..d76c18e 100644 --- i/doc/src/sgml/ref/vacuumdb.sgml +++ w/doc/src/sgml/ref/vacuumdb.sgml @@ -403,9 +403,10 @@ PostgreSQL documentation -This option is useful to analyze a database that was newly populated +This option is useful to analyze a database that current has no, +or bad, statistics e.g. it was newly populated from a restored dump or by pg_upgrade. This option -will try to create some statistics as fast as possible, to make the +will create coarse statistics as fast as possible, to make the database usable, and then produce full statistics in the subsequent stages. signature.asc Description: OpenPGP digital signature
9.17. Sequence Manipulation Functions
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/functions-sequence.html Description: Just a slip of the pen in the table "Function Description", in tha string: "setval ( regclass, bigint [, boolean ] ) → bigint", i think that something incorrect with the second comma. Thanks!
Re: small patch
On Thu, 2021-10-07 at 16:06 -0400, rir wrote: > > > > - we should retain "empty or one of", otherwise the following syntax > > > > would be undocumented: > > For myself, >'FETCH [ [ FROM | IN ] ] ' > clearly indicates that 'direction' is optional. Yes, but since [ FROM | IN ] is inside the bracket, that diagram would not account for "direction" being omitted while retaining FROM. So I suggest that you change the syntax diagram to FETCH [ direction ] [ FROM | IN ] cursor_name Then I agree that the "empty or" can be removed. I think that would be a good idea, and it would add clarity. I remain of the opinion that the comments should be retained, but we can leave that for somebody else to decide. Do you want to prepare a new patch and register it in the commitfest? Yours, Laurenz Albe
Re: 9.17. Sequence Manipulation Functions
On Fri, Oct 8, 2021 at 12:12 PM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/functions-sequence.html > Description: > > Just a slip of the pen in the table "Function Description", in tha string: > "setval ( regclass, bigint [, boolean ] ) → bigint", i think that something > incorrect with the second comma. Thanks! > I don't see anything wrong. The square brackets show that this (3rd) parameter is optional. If you use three parameters then you need a comma between the 2nd and 3rd. It's common to see [, parameter ] in function definitions. Look in text functions for many similar examples. Best regards, Pantelis Theodosiou
