pgsql: Change get_constraint_index() to use pg_constraint.conindid
Change get_constraint_index() to use pg_constraint.conindid It was still using a scan of pg_depend instead of using the conindid column that has been added since. Since it is now just a catalog lookup wrapper and not related to pg_depend, move from pg_depend.c to lsyscache.c. Reviewed-by: Matthias van de Meent Reviewed-by: Tom Lane Reviewed-by: Michael Paquier Discussion: https://www.postgresql.org/message-id/flat/4688d55c-9a2e-9a5a-d166-5f24fe0bf8db%40enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8b069ef5dca97cd737a5fd64c420df3cd61ec1c9 Modified Files -- src/backend/catalog/pg_depend.c | 69 src/backend/commands/tablecmds.c | 1 - src/backend/optimizer/util/plancat.c | 1 - src/backend/utils/adt/ruleutils.c| 3 +- src/backend/utils/cache/lsyscache.c | 27 ++ src/include/catalog/dependency.h | 2 -- src/include/utils/lsyscache.h| 1 + 7 files changed, 29 insertions(+), 75 deletions(-)
pgsql: Support subscripting of arbitrary types, not only arrays.
Support subscripting of arbitrary types, not only arrays. This patch generalizes the subscripting infrastructure so that any data type can be subscripted, if it provides a handler function to define what that means. Traditional variable-length (varlena) arrays all use array_subscript_handler(), while the existing fixed-length types that support subscripting use raw_array_subscript_handler(). It's expected that other types that want to use subscripting notation will define their own handlers. (This patch provides no such new features, though; it only lays the foundation for them.) To do this, move the parser's semantic processing of subscripts (including coercion to whatever data type is required) into a method callback supplied by the handler. On the execution side, replace the ExecEvalSubscriptingRef* layer of functions with direct calls to callback-supplied execution routines. (Thus, essentially no new run-time overhead should be caused by this patch. Indeed, there is room to remove some overhead by supplying specialized execution routines. This patch does a little bit in that line, but more could be done.) Additional work is required here and there to remove formerly hard-wired assumptions about the result type, collation, etc of a SubscriptingRef expression node; and to remove assumptions that the subscript values must be integers. One useful side-effect of this is that we now have a less squishy mechanism for identifying whether a data type is a "true" array: instead of wiring in weird rules about typlen, we can look to see if pg_type.typsubscript == F_ARRAY_SUBSCRIPT_HANDLER. For this to be bulletproof, we have to forbid user-defined types from using that handler directly; but there seems no good reason for them to do so. This patch also removes assumptions that the number of subscripts is limited to MAXDIM (6), or indeed has any hard-wired limit. That limit still applies to types handled by array_subscript_handler or raw_array_subscript_handler, but to discourage other dependencies on this constant, I've moved it from c.h to utils/array.h. Dmitry Dolgov, reviewed at various times by Tom Lane, Arthur Zakirov, Peter Eisentraut, Pavel Stehule Discussion: https://postgr.es/m/CA+q6zcVDuGBv=m0fqbyx8dpebs3f_0kq6ovfobgjpm507_s...@mail.gmail.com Discussion: https://postgr.es/m/ca+q6zcvovr+xy4mfk-7onk-rf91gh0pebnnfuujuudsyhjo...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c7aba7c14efdbd9fc1bb44b4cb83bedee0c6a6fc Modified Files -- contrib/postgres_fdw/deparse.c| 15 +- doc/src/sgml/catalogs.sgml| 38 +- doc/src/sgml/ref/create_type.sgml | 76 +++- src/backend/catalog/aclchk.c | 4 +- src/backend/catalog/dependency.c | 16 + src/backend/catalog/heap.c| 2 + src/backend/catalog/pg_type.c | 11 +- src/backend/commands/typecmds.c | 95 - src/backend/executor/execExpr.c | 150 src/backend/executor/execExprInterp.c | 238 +--- src/backend/jit/llvm/llvmjit_expr.c | 78 ++-- src/backend/jit/llvm/llvmjit_types.c | 5 +- src/backend/nodes/copyfuncs.c | 1 + src/backend/nodes/equalfuncs.c| 1 + src/backend/nodes/nodeFuncs.c | 11 +- src/backend/nodes/outfuncs.c | 1 + src/backend/nodes/readfuncs.c | 1 + src/backend/optimizer/util/clauses.c | 43 ++- src/backend/parser/parse_coerce.c | 5 +- src/backend/parser/parse_collate.c| 23 ++ src/backend/parser/parse_expr.c | 6 +- src/backend/parser/parse_node.c | 231 src/backend/parser/parse_target.c | 48 ++- src/backend/utils/adt/Makefile| 1 + src/backend/utils/adt/arrayfuncs.c| 6 +- src/backend/utils/adt/arraysubs.c | 577 ++ src/backend/utils/adt/format_type.c | 8 +- src/backend/utils/adt/jsonfuncs.c | 3 +- src/backend/utils/cache/lsyscache.c | 67 +++- src/backend/utils/cache/typcache.c| 2 + src/bin/pg_dump/pg_dump.c | 15 + src/include/c.h | 8 - src/include/catalog/catversion.h | 2 +- src/include/catalog/pg_proc.dat | 8 + src/include/catalog/pg_type.dat | 39 +- src/include/catalog/pg_type.h | 30 +- src/include/executor/execExpr.h | 56 +-- src/include/nodes/primnodes.h | 42 ++- src/include/nodes/subscripting.h | 167 + src/include/parser/parse_node.h | 6 +- src/include/utils/array.h | 5 + src/include/utils/lsyscache.h | 6 + src/include/utils/typcache.h | 1 + src/pl/plperl/plperl.c| 6 +- src/pl/plpgsql/src/pl_comp.c | 4 +- src/pl/plpython/plpy_typeio.c | 8 +- src/test/regress/expected/arrays.out
Re: pgsql: Support subscripting of arbitrary types, not only arrays.
On Wed, Dec 9, 2020 at 8:40 PM Tom Lane wrote: > Support subscripting of arbitrary types, not only arrays. Nice to see this committed! BTW, it seems typedefs.list needs to be adjusted. -- Regards, Alexander Korotkov generic_subsciption_typedefs.patch Description: Binary data
pgsql: Refactor MD5 implementations according to new cryptohash infrast
Refactor MD5 implementations according to new cryptohash infrastructure This commit heavily reorganizes the MD5 implementations that exist in the tree in various aspects. First, MD5 is added to the list of options available in cryptohash.c and cryptohash_openssl.c. This means that if building with OpenSSL, EVP is used for MD5 instead of the fallback implementation that Postgres had for ages. With the recent refactoring work for cryptohash functions, this change is straight-forward. If not building with OpenSSL, a fallback implementation internal to src/common/ is used. Second, this reduces the number of MD5 implementations present in the tree from two to one, by moving the KAME implementation from pgcrypto to src/common/, and by removing the implementation that existed in src/common/. KAME was already structured with an init/update/final set of routines by pgcrypto (see original pgcrypto/md5.h) for compatibility with OpenSSL, so moving it to src/common/ has proved to be a straight-forward move, requiring no actual manipulation of the internals of each routine. Some benchmarking has not shown any performance gap between both implementations. Similarly to the fallback implementation used for SHA2, the fallback implementation of MD5 is moved to src/common/md5.c with an internal header called md5_int.h for the init, update and final routines. This gets then consumed by cryptohash.c. The original routines used for MD5-hashed passwords are moved to a separate file called md5_common.c, also in src/common/, aimed at being shared between all MD5 implementations as utility routines to keep compatibility with any code relying on them. Like the SHA2 changes, this commit had its round of tests on both Linux and Windows, across all versions of OpenSSL supported on HEAD, with and even without OpenSSL. Author: Michael Paquier Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/20201106073434.ga4...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b67b57a966af0c4a9547ac6fff334d3c256d9c2a Modified Files -- contrib/pgcrypto/Makefile | 2 +- contrib/pgcrypto/internal.c| 25 +- contrib/pgcrypto/md5.c | 397 -- src/common/Makefile| 3 +- src/common/cryptohash.c| 13 + src/common/cryptohash_openssl.c| 3 + src/common/md5.c | 683 ++--- src/common/md5_common.c| 149 ++ contrib/pgcrypto/md5.h => src/common/md5_int.h | 60 ++- src/include/common/cryptohash.h| 3 +- src/include/common/md5.h | 5 +- src/tools/msvc/Mkvcbuild.pm| 12 +- src/tools/pgindent/typedefs.list | 1 + 13 files changed, 613 insertions(+), 743 deletions(-)
Re: pgsql: Support subscripting of arbitrary types, not only arrays.
Alexander Korotkov writes: > BTW, it seems typedefs.list needs to be adjusted. There's no particular consensus so far that typedefs.list should be maintained on-the-fly. Checking the version in git against what the buildfarm is reporting shows a *lot* of diffs besides this, so I'm hardly the only one not updating it. (I'd be happy to sign onto such maintenance if we were also doing something to keep HEAD pgindent'd on a more continuous basis. See prior discussions.) regards, tom lane
Re: pgsql: Refactor MD5 implementations according to new cryptohash infrast
On Thu, Dec 10, 2020 at 03:01:20AM +, Michael Paquier wrote: > Refactor MD5 implementations according to new cryptohash infrastructure > > This commit heavily reorganizes the MD5 implementations that exist in > the tree in various aspects. > > First, MD5 is added to the list of options available in cryptohash.c and > cryptohash_openssl.c. This means that if building with OpenSSL, EVP is > used for MD5 instead of the fallback implementation that Postgres had > for ages. With the recent refactoring work for cryptohash functions, > this change is straight-forward. If not building with OpenSSL, a > fallback implementation internal to src/common/ is used. And this has broken uuid-ossp. The switch is quite easy to do as this module just needs to use cryptohash APIs for MD5. Will fix in a minute.. -- Michael signature.asc Description: PGP signature
pgsql: Fix compilation of uuid-ossp
Fix compilation of uuid-ossp This module had a dependency on pgcrypto's md5.c that got removed by b67b57a. Instead of the code from pgcrypto, this code can just use the new cryptohash routines for MD5 as a drop-in replacement, so let's just do this switch. This has also the merit to simplify a bit the compilation of uuid-ossp. This requires --with-uuid to be reproduced, and I have used e2fs as a way to reproduce the failure, then test this commit. Per reports from buildfarm members longfin, florican and sifaka. Discussion: https://postgr.es/m/x9gtovd3qmwen...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/525e60b7429925d09fce1b5aa0bc2f23cfe6dd18 Modified Files -- configure | 4 ++-- configure.ac | 4 ++-- contrib/uuid-ossp/Makefile| 4 ++-- contrib/uuid-ossp/uuid-ossp.c | 16 ++-- 4 files changed, 16 insertions(+), 12 deletions(-)
Re: pgsql: Refactor MD5 implementations according to new cryptohash infrast
On Thu, Dec 10, 2020 at 12:18:57PM +0900, Michael Paquier wrote: > And this has broken uuid-ossp. The switch is quite easy to do as this > module just needs to use cryptohash APIs for MD5. Will fix in a > minute.. So, I have reproduced the failure with --with-uuid=e2fs and now fixed it with 525e60b. FWIW, I got to wonder this morning whether we should have a sha1 option for cryptohash.c, and seeing how ugly is the dependency on md5.c and sha1.c between pgcrypto and uuid-ossp, this may give an extra reason to do so.. -- Michael signature.asc Description: PGP signature
