Fwd: [PATCH] pg_dump: Add example and link for --encoding option
2020년 6월 5일 (금) 오후 9:45, 이동욱 님이 작성: > I've modified my previous patch because it linked the wrong document so I > fixed it. and I add a highlight to the encoding list for readability. > > What do you think about this change? > > Thanks, > Dong Wook > > 2020년 6월 4일 (목) 오후 10:20, 이동욱 님이 작성: > >> To let users know what kind of character set >> can be used add examples and a link to --encoding option. >> >> Thanks, >> Dong wook >> > From 890ab97aa211dc6fe99ce54bc5522afd5d614081 Mon Sep 17 00:00:00 2001 From: Lee Dong Wook Date: Thu, 4 Jun 2020 21:54:33 +0900 Subject: [PATCH] pg_dump: Add example and link for --encoding option To let users know what kind of character set can be used add examples and a link to --encoding option. --- doc/src/sgml/ref/pg_dump.sgml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml index 197b5c0d70..9915f35f14 100644 --- a/doc/src/sgml/ref/pg_dump.sgml +++ b/doc/src/sgml/ref/pg_dump.sgml @@ -226,6 +226,8 @@ PostgreSQL documentation the dump is created in the database encoding. (Another way to get the same result is to set the PGCLIENTENCODING environment variable to the desired dump encoding.) +You can also use variable character set (i.e. UTF8, EUC_KR, EUC_JP, EUC_CN ... etc) +and you can see the all supported character set in PostgreSQL (see ) -- 2.23.0
Not using suppress_redundant_updates_trigger in sql-createtrigger.html#examples
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/bug-reporting.html Description: Hi I was stumbling across the trigger function ‘suppress_redundant_updates_trigger’ in https://www.postgresql.org/docs/devel/functions-trigger.html and I would just ask if there is any reason of this not being int the documentation in https://www.postgresql.org/docs/13/sql-createtrigger.html. So after Call a function to log updates of accounts, but only if something changed: CREATE TRIGGER log_update AFTER UPDATE ON accounts FOR EACH ROW WHEN (OLD.* IS DISTINCT FROM NEW.*) EXECUTE FUNCTION log_account_update(); There could be an alternative implementation as well CREATE TRIGGER log_update AFTER UPDATE ON accounts FOR EACH ROW EXECUTE FUNCTION log_account_update(); CREATE TRIGGER suppress_redundant_account_after_updates AFTER UPDATE ON accounts FOR EACH ROW EXECUTE FUNCTION suppress_redundant_updates_trigger(); Just to introduce and like the feature. Thank you for your great work best regards
Replication Binary in PostgreSQL 12
Hello, I am implementing binary replication in PostgreSQL 12. I have a lot of pending questions. Example, how to know a subscriber is up to date, if there is the possibility of knowing if the subscriber is currently connected to the publication, etc, etc. Where can I get more documentation?
Re: Documentation 9.8. Data Type Formatting Functions: missing behaviour on invalid input at to_date()
On Fri, Jun 5, 2020 at 11:16:59AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/functions-formatting.html > Description: > > For the formatting functions, which convert between a string and a type like > date, timestamp or number, there should be a description about the behaviour > of i.e. to_date(input, mask) in case of invalid, not convertable input. > > I expected a return value of NULL and got a execution error. Well, the value isn't "unknown", it is invalid, so an error seems appropriate. I don't remember anyone complaining the expected a NULL return. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Re: create database with template doesn't copy ACL
On Fri, Jun 5, 2020 at 02:31:34PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/sql-createdatabase.html > Description: > > My understanding is that not copying the ACL is the (currently) expected > behavior when issuing CREATE DATABASE newdb WITH TEMPLATE my_tmpl; > It would be useful for the documentation to note this caveat. Uh, what ACLs are not copied? -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Re: Documentation 9.8. Data Type Formatting Functions: missing behaviour on invalid input at to_date()
On Fri, Jun 12, 2020 at 2:28 PM Bruce Momjian wrote: > On Fri, Jun 5, 2020 at 11:16:59AM +, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/12/functions-formatting.html > > Description: > > > > For the formatting functions, which convert between a string and a type > like > > date, timestamp or number, there should be a description about the > behaviour > > of i.e. to_date(input, mask) in case of invalid, not convertable input. > > > > I expected a return value of NULL and got a execution error. > > Well, the value isn't "unknown", it is invalid, so an error seems > appropriate. I don't remember anyone complaining the expected a NULL > return. > The complaint is about us not explicitly documenting which of "error" or "null" is the outcome so the reader is left to assume or test it themselves. The OP isn't saying our choice is wrong, just our lack of documentation of said choice. I believe the current reality is the user should assume that problems result in errors unless the function documents that it will return NULL. David J.
