Re: Update encryption options doc for SCRAM-SHA-256
Thanks for your attention to this. I'm definitely not a cryptography expert, but it seems to me that the actual mechanisms (MD5, SHA-256) are more important than the protocols used to negotiate them (SASL, SCRAM). When some security expert unfamiliar with PostgreSQL goes over itss documentation to determine whether it's secure, I think it's important to make sure that the word SHA-256 is actually there. On Sat, Feb 3, 2018 at 8:30 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2/2/18 18:42, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/10/static/encryption-options.html > > Description: > > > > Section "18.8. Encryption Options" only mentions MD5 as the password > storage > > encryption mechanism, although PostgreSQL 10 introduced the superior > SHA256 > > - somebody looking at the docs would get a bad idea of PostgreSQL's > > capabilities... > > I propose the attached patch. I have combined the password storage and > password transmission items, because I don't want to go into the details > of how SCRAM works on the wire. > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Re: Signed-ness of ints is unclear in FE-BE protocol docs
> > Second, across the protocol docs, rather than using Int32 and Int64, > which > > generally look like they're signed (depending on which language you're > > coming from), I'd consider using UInt32/UInt64, which are unambiguous > with > > regards to signed-ness. > > Well, they are actually signed, so I'm confused why you think we should > change the documentation to unsigned. > Interesting... I'm not 100% sure, but I recently received a report that the WAL coordinates in XLogData ( https://www.postgresql.org/docs/current/protocol-replication.html) are unsigned longs, is that a mistake? Are you saying all values in the protocol are always signed?
Incorrect and missing docs for range_intersect_agg
Hi all, range_intersect_agg is documented to return anymultirange (on this page[1]), but it actually returns a range. In addition, range_intersect_agg also accepts a multirange as its parameter, but that's not documented on the same page. Note that range_agg does *not* accept a multirange (possibly already added for PG15, see this[2]). Thanks, Shay [1] https://www.postgresql.org/docs/current/functions-aggregate.html [2] https://www.mail-archive.com/pgsql-hackers@lists.postgresql.org/msg105057.html
Lower/upper-case consistency with function names
Hi all, The PostgreSQL docs mostly show function names in lowercase (e.g. [1], [2]), which seems to be the PostgreSQL-idiomatic thing to do. However, some pages show functions in upper case, e.g. COALESCE/NULLIF/GREATEST/LEAST ([3]). Is there some difference between these which warrants the case difference, or just a case of docs inconsistency? I ran into this while trying to make Entity Framework (.NET ORM) generate more idiomatic-looking SQL. If this is just an inconsistency, it's obviously not very important. Thanks, Shay [1] https://www.postgresql.org/docs/current/functions-aggregate.html [2] https://www.postgresql.org/docs/current/datatype-datetime.html [3] https://www.postgresql.org/docs/current/functions-conditional.html
Re: Lower/upper-case consistency with function names
On Sun, Jun 5, 2022 at 10:27 AM Julien Rouhaud wrote: > As mentioned in the doc in [3], COALESCE and all the others are actually not functions (those are specific keywords handled in the parser): Thanks. Yeah, I noticed that comment, but NULLIF which is also documented on that page isn't mentioned in that comment, but it's still shown in upper-case. It's maybe worth adding NULLIF to that comment. I'm also not sure I'd consider real/not real distinction as something that's very relevant to the user, to the extent that it warrants a case difference... But that doesn't matter much.
Clarify the ordering guarantees in combining queries (or lack thereof)
Greetings. I was trying to understand what - if any - are the guarantees with regards to ordering for combining queries (UNION/UNION ALL/...). From this message[1], it seems that UNION ALL does preserve the ordering of the operand queries, whereas UNION does not (presumably neither do INTERSECT, INTERSECT ALL, EXCEPT and EXCEPT ALL). The documentation[2] makes no mention of this, I'd suggest adding a note clarifying this. Thanks, Shay [1] https://www.postgresql.org/message-id/26825.1064858...@sss.pgh.pa.us [2] https://www.postgresql.org/docs/current/queries-union.html
Re: Clarify the ordering guarantees in combining queries (or lack thereof)
>> I was trying to understand what - if any - are the guarantees with regards to ordering for combining queries (UNION/UNION ALL/...). From this message[1], it seems that UNION ALL does preserve the ordering of the operand queries, whereas UNION does not (presumably neither do INTERSECT, INTERSECT ALL, EXCEPT and EXCEPT ALL). >> >> The documentation[2] makes no mention of this, I'd suggest adding a note clarifying this. > > If you want ordered output use ORDER BY. I don't see how that could be done. Consider the following: (SELECT id FROM data ORDER BY id) UNION ALL (SELECT id FROM data ORDER BY id DESC); If there's a guarantee that UNION ALL preserves ordering - as Tom seems to indicate in the thread quoted above - then the above works. If there's no such guarantee, then AFAIK the above can't be rewritten; putting the ORDER BY outside - on the results of the UNION ALL - would order all results rather than preserving each resultset's ordering. [1] https://www.postgresql.org/message-id/26825.1064858...@sss.pgh.pa.us [2] https://www.postgresql.org/docs/current/queries-union.html
Re: Clarify the ordering guarantees in combining queries (or lack thereof)
>> No, there is no guarantee. It's just that UNION ALL works this way today >> (preserving the order of the subselects) - and I'm not even sure about >> that, it may not preserve the order in all cases, with different indexes or >> partitioning or a parallel plan, etc. > > Yeah, that. You can get a parallelized plan today for UNION ALL: ... > Since the documentation doesn't make a guarantee there is none. Thanks all for the confirmation. I'd still suggest documenting the lack of guarantee; yes, mathematically it may be correct to not document lack of guarantees, but users can come with various expectations and misunderstandings (I also wasn't clear on this specifically for UNION ALL), and it's always good to say this kind of thing explicitly.
