pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Mark internal_in as not strict, so that the construct
2+ messages / 2 participants
[nested] [flat]
* pgsql: Mark internal_in as not strict, so that the construct
@ 2009-06-09 19:51 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 2+ messages in thread
From: tgl@postgresql.org @ 2009-06-09 19:51 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Mark internal_in as not strict, so that the construct "null::internal"
will throw an error, rather than possibly allowing someone to synthesize
a manual call to an internal-accepting function. As of CVS HEAD and existing
releases, all such functions are either STRICT or careful about null inputs,
so there is no current security issue here. But it seems like a good idea
to lock this down to protect against future mistakes.
In passing, similarly lock down trigger_in, language_handler_in, opaque_in,
and shell_in. These are not believed to present any security risk, but
there's still no good reason to allow nulls of these types to be created.
I left the polymorphic pseudotypes (anyelement etc) alone, since a null
of one of those types doesn't seem to be a problem --- the worst you can
say about it is that it doesn't have an underlying non-polymorphic type.
If we were to make this change during normal development, we'd just
automatically bump catversion for a pg_proc.h change. But since this doesn't
create a compatibility risk and isn't believed to be fixing a live bug, it
seems better not to force a catversion bump in late beta.
Modified Files:
--------------
pgsql/src/include/catalog:
pg_proc.h (r1.542 -> r1.543)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h?r1=1.542&r2=1.543)
^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Remove unneeded nbtree array preprocessing assert.
@ 2024-04-22 17:58 Peter Geoghegan <pg@bowt.ie>
0 siblings, 0 replies; 2+ messages in thread
From: Peter Geoghegan @ 2024-04-22 17:58 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Remove unneeded nbtree array preprocessing assert.
Certain cases involving the use of cursors had assertion failures within
_bt_preprocess_keys's recently added no-op return path. The assertion
in question made the faulty assumption that a second or third call to
_bt_preprocess_keys (within the same btrescan) could only happen when
another scheduled primitive index scan was just about to begin.
It would be possible to address the problem by only allowing scans that
have array keys to take the new no-op path, forcing affected cases to
perform redundant preprocessing work. It seems simpler to just remove
the assertion, and reframe the no-op path as a more general mechanism.
Take this simpler approach.
The important underlying principle is that we only need to perform
preprocessing once per btrescan (at most). This is expected regardless
of whether or not the scan happens to have array keys.
Oversight in commit 1b134ca5, which enhanced nbtree ScalarArrayOp
execution.
Reported-By: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/ef0f7c8b-a6fa-362e-6fd6-054950f947ca@gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/480bc6e3ed3a5719cdec076d4943b119890e8171
Modified Files
--------------
src/backend/access/nbtree/nbtutils.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-04-22 17:58 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-06-09 19:51 pgsql: Mark internal_in as not strict, so that the construct Tom Lane <tgl@postgresql.org>
2024-04-22 17:58 pgsql: Remove unneeded nbtree array preprocessing assert. Peter Geoghegan <pg@bowt.ie>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox