pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Use (unsigned char) cast in argument of pg_tolower().
4+ messages / 2 participants
[nested] [flat]
* pgsql: Use (unsigned char) cast in argument of pg_tolower().
@ 2009-04-03 23:27 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 4+ messages in thread
From: tgl@postgresql.org @ 2009-04-03 23:27 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Use (unsigned char) cast in argument of pg_tolower(). Maybe it works on
Windows without that, but we shouldn't put bad examples where people might
copy them. Also, reformat slightly to improve the odds that pgindent
won't go nuts on this.
Modified Files:
--------------
pgsql/src/port:
path.c (r1.77 -> r1.78)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/path.c?r1=1.77&r2=1.78)
^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Use (unsigned char) cast in argument of pg_tolower().
@ 2009-04-03 23:27 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 4+ messages in thread
From: tgl@postgresql.org @ 2009-04-03 23:27 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Use (unsigned char) cast in argument of pg_tolower(). Maybe it works on
Windows without that, but we shouldn't put bad examples where people might
copy them. Also, reformat slightly to improve the odds that pgindent
won't go nuts on this.
Tags:
----
REL8_3_STABLE
Modified Files:
--------------
pgsql/src/port:
path.c (r1.74.2.1 -> r1.74.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/path.c?r1=1.74.2.1&r2=1.74.2.2)
^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Use (unsigned char) cast in argument of pg_tolower().
@ 2009-04-03 23:27 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 4+ messages in thread
From: tgl@postgresql.org @ 2009-04-03 23:27 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Use (unsigned char) cast in argument of pg_tolower(). Maybe it works on
Windows without that, but we shouldn't put bad examples where people might
copy them. Also, reformat slightly to improve the odds that pgindent
won't go nuts on this.
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pgsql/src/port:
path.c (r1.70.2.1 -> r1.70.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/path.c?r1=1.70.2.1&r2=1.70.2.2)
^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Allow more cases to pass the unsafe-use-of-new-enum-value restri
@ 2024-03-24 18:30 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 4+ messages in thread
From: Tom Lane @ 2024-03-24 18:30 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Allow more cases to pass the unsafe-use-of-new-enum-value restriction.
Up to now we've rejected cases like
BEGIN;
CREATE TYPE rainbow AS ENUM ();
ALTER TYPE rainbow ADD VALUE 'red';
-- use the value 'red', perhaps in a constraint or index
COMMIT;
The concern is that the uncommitted enum value 'red' might get into
an index and then break the index if we roll back the ALTER ADD.
If the ALTER is in the same transaction as the CREATE then it's really
perfectly safe, but we weren't taking the trouble to identify that.
pg_dump in binary-upgrade mode will emit enum definitions that look
like the above, which up to now didn't fall foul of the unsafe-usage
check because we processed each restore command as a separate
transaction. However an upcoming patch proposes to bundle the restore
commands into large transactions to reduce XID consumption during
pg_upgrade, and that makes this behavior a problem.
To fix, remember the OIDs of enum types created in the current
transaction, and allow use of enum values that are added to one later
in the same transaction. To do this fully correctly in the presence
of subtransactions, we'd have to track subtransaction nesting level of
the CREATE and do maintenance work at every subsequent subtransaction
exit. That seems expensive, and we don't need it to satisfy pg_dump's
usage. Hence, apply the additional optimization only when the CREATE
and ALTER are at outermost transaction level.
Patch by me, reviewed by Andrew Dunstan
Discussion: https://postgr.es/m/1548468.1711220438@sss.pgh.pa.us
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/af1d3958432c9438c4ec168bd16bdf9a91066a9f
Modified Files
--------------
src/backend/catalog/pg_enum.c | 208 +++++++++++++++++++++++++++++--------
src/backend/utils/adt/enum.c | 19 ++--
src/test/regress/expected/enum.out | 12 ++-
src/test/regress/sql/enum.sql | 5 +-
4 files changed, 181 insertions(+), 63 deletions(-)
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-03-24 18:30 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-04-03 23:27 pgsql: Use (unsigned char) cast in argument of pg_tolower(). Tom Lane <tgl@postgresql.org>
2009-04-03 23:27 pgsql: Use (unsigned char) cast in argument of pg_tolower(). Tom Lane <tgl@postgresql.org>
2009-04-03 23:27 pgsql: Use (unsigned char) cast in argument of pg_tolower(). Tom Lane <tgl@postgresql.org>
2024-03-24 18:30 pgsql: Allow more cases to pass the unsafe-use-of-new-enum-value restri Tom Lane <tgl@sss.pgh.pa.us>
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