Re: UUID v7
> On 23 Nov 2024, at 10:58, Masahiko Sawada wrote: > > I've attached an updated patch that squashed changes I made for v33. > We're still discussing increasing entropy on Windows and macOS, but > the patch seems to be in good shape. +1, thanks! PFA version with improved comment. Sergey Prokhorenko just draw my attention to the new release of MariaDB [0]. They are doing very similar UUID v7 generation as we do [1]. Best regards, Andrey Borodin. [0] https://mariadb.com/resources/blog/announcing-mariadb-community-server-11-7-rc-with-vector-search-and-11-6-ga/ [1] https://github.com/mariadb/server/blob/main/plugin/type_uuid/sql_type_uuid_v7.h#L32 v37-0001-Implement-UUID-v7.patch Description: Binary data v37-0002-Mix-in-2-bits-of-entropy-into-timestampt-of-UUID.patch Description: Binary data
Re: Document NULL
Em qui., 21 de nov. de 2024 às 12:04, David G. Johnston < david.g.johns...@gmail.com> escreveu: Typo in NuLl, mixed upper and lower case. SELECT NULL AS "Literal Null Value", pg_typeof(null) AS "Type of Null", pg_typeof(NuLl::text) AS "Type of Cast null", cast(null as text) AS "Cast null value"; should be pg_typeof(null::text) AS "Type of Cast Null",
Use or not record count on examples
There is no rule of when the number of records at the end of the lists
should be shown or not
Sometimes we show that line "(4 rows)", but sometimes not.
Should we have a standard for it ? Should we add them all or remove them
all ?
I think they are useless. Or maybe shown when no rows are returned.
datatype.sgml
a | char_length
--+-
ok | 2
name | current_mood
--+--
Moe | happy
(1 row)
func.sgml
a | b
---+-
1 | foo
2 |
make | model | sales
---+---+---
Foo | GT| 10
Foo | Tour | 20
Bar | City | 15
Bar | Sport | 5
(4 rows)
Or maybe when not all records are shown, like in planstats.sgml
index | values | nulls | frequency | base_frequency
---+--+---+---+
0 | {0, 0} | {f,f} | 0.01 | 0.0001
1 | {1, 1} | {f,f} | 0.01 | 0.0001
...
49 | {49, 49} | {f,f} | 0.01 | 0.0001
50 | {50, 50} | {f,f} | 0.01 | 0.0001
...
97 | {97, 97} | {f,f} | 0.01 | 0.0001
98 | {98, 98} | {f,f} | 0.01 | 0.0001
99 | {99, 99} | {f,f} | 0.01 | 0.0001
(100 rows)
regards
Marcos
Re: [BUG?] check_exclusion_or_unique_constraint false negative
Hello, everyone! A rebased version is attached. Also, fixed potential race in the test and detailed commit messages. Best regards, Mikhail. > v3-0001-Fix-possible-lost-tuples-in-non-MVCC-index-scans-.patch Description: Binary data v3-0002-Add-isolation-test-to-reproduce-dirty-snapshot-sc.patch Description: Binary data
Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
On 11/22/24 09:11, Daniel Gustafsson wrote: On 21 Nov 2024, at 22:39, Joe Conway wrote: I mean, perhaps I am misreading and/or interpreting all of that differently to you, but from my reading of the entire thread there was clearly no consensus to using openssl to provide those two functions. My interpretation (or perhaps, my opinion) is that it would be ideal to reimplement these functions using OpenSSL *if possible* but the cost/benefit ratio is probably tilted such that it will never happen. [..] we don't drag this out past pg18 feature freeze Agreed. If you have a better patch you would like to propose to fix this problem, please do. I'm still not thrilled about having a transitive dependency GUC, so attached is a (very lightly tested POC) version of your patch which expands it from boolean to enum with on/off/fips; the fips value being "disable if openssl is in fips mode, else enable". I'm not sure if that's better, but at least it gives users a way to control the FIPS mode setting in one place and have crypto consumers follow the set value (or they can explicitly turn it off if they just want them disabled even without FIPS). Works for me. I do wonder if the GUC should be PGC_POSTMASTER (as I had suggested it ought to be in an earlier post) rather than PGC_SUSET (which was the way my posted patch had it). But perhaps PGC_SUSET is sufficient, and it makes testing easier. One other question this spawned -- do we document the minimum supported version of OpenSSL anywhere? I remembered it had recently been increased, but could only find confirmation in the git logs that 1.1.1 was now the minimum. -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Re: Forbid to DROP temp tables of other sessions
> On 22 Nov 2024, at 03:02, Andres Freund wrote: > > I don't > love having to put RELATION_IS_OTHER_TEMP() checks everywhere either. +1. I do not understand why this restriction (protecting temp tables from access) is a responsibility of the buffer manager. Actually, I like the idea that superuser knows better what to do. What if we say it's not a bug, but a feature. Will it break some contracts with user or some functionality? It seems that protection of temp tables should belong to ACL stuff. And in a logic of this subsystem would be natural to just allow superuser do whatever they want with. Is it some lunatic idea? Or does it make some sense? Best regards, Andrey Borodin.
