diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2023-05-04 11:00:33 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2023-05-04 11:00:33 -0400 |
| commit | b7fcf3824b42c43458121ada1f74e111ca987d4d (patch) | |
| tree | 0b28fae680b8d28e8f03f9d9fe17b1bde6d4e12a /src/backend/utils/adt/array_userfuncs.c | |
| parent | 825828956ab3c55bd22259d9c480b5f5d2d84416 (diff) | |
| download | postgresql-b7fcf3824b42c43458121ada1f74e111ca987d4d.tar.gz postgresql-b7fcf3824b42c43458121ada1f74e111ca987d4d.zip | |
Tighten array dimensionality checks in Python -> SQL array conversion.
Like plperl before f47004add, plpython wasn't being sufficiently
careful about checking that list-of-list structures represent
rectangular arrays, so that it would accept some cases in which
different parts of the "array" are nested to different depths.
This was exacerbated by Python's weak distinction between
sequences and lists, so that in some cases strings could get
treated as though they are lists (and burst into individual
characters) even though a different ordering of the upper-level
list would give a different result.
Some of this behavior was unreachable (without risking a crash)
before 81eaaf65e. It seems like a good idea to clean it all up
in the same releases, rather than shipping a non-crashing but
nonetheless visibly buggy behavior in the name of minimal change.
Hence, back-patch.
Per bug #17912 and further testing by Alexander Lakhin.
Discussion: https://postgr.es/m/17912-82ceed78731d9cdc@postgresql.org
Diffstat (limited to 'src/backend/utils/adt/array_userfuncs.c')
0 files changed, 0 insertions, 0 deletions