Re: 9.4. String Functions and Operators page does not document that encode adds line breaks
On 2020-Feb-09, David G. Johnston wrote:
> Stating direct RFC4648 compliance would require us to drop the line breaks
> that are only being added due to using MIME rules which ideally our general
> encoding function would not do. Greenfield we probably would want base64
> to be general RFC4648 and add something like base64-mime which performs the
> line breaking for the user per RFC 2045, base64-pem which would use that
> specific environments RFC rules. Now, maybe we can add "base64-4648" or
> "base64-general" while leaving "base64" alone and using the MIME version of
> the rules?
Patches welcome.
I'm not sure that we *need* to preserve the historical behavior. Many
people would probably be okay with encode('base64') returning no
newlines (since they are useless most of the time anyway), and the
minority that does can use encode('base64-rfc2045').
Another idea might be to add an optional 'flags' option to encode(),
which are given to the encoder/decoder functions.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
explanation for random_page_cost is outdated
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/runtime-config-query.html Description: Explanation for random_page_cost is rather outdated, because it did only for case of mechanical hdd. But all modern database servers, which I know, made upon SSD. Do or not do default value for random_page_cost equal to 1 is the question, but, IMHO, at list in the documentation about random_page_cost need to add in a speculation about SSD. It's important because a business programming now is mostly web programming. Most database is poorly designed by web programmer, tables looked like a primary key and a huge json (containing all) with large gin index upon it. Now I am seeing a table with a GIN index 50% of the table size. The database is on SSD, of cause. With default random_page_cost=4 GIN index don't used by planner, but with random_page_cost=1 the result may be not excellent, but acceptable for web programmers.
thoroughly broken examples on the Dynamic SQL page
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/ecpg-dynamic.html Description: Has anyone tried the examples on the https://www.postgresql.org/docs/11/ecpg-dynamic.html Dynamic SQL page? The very first line in each example immediately throws a syntax error: "syntax error at or near "exec"". Could we get this updated or a bug fixed? I'm migrating from SQL Server and really need to know how to migrate dynamic SQL in existing code.
