Remove obsolete comment.
Commit 755a4c10d19d prevented StartReadBuffers() from crossing md.c
segment boundaries in one operation, but a comment about that
possibility remained.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/9e17ac997f921c9de99125a97a0f34ae50f5c498
Remove unused parameter from execute_extension_script().
This function's schemaOid parameter appears to have never been used
for anything.
Author: Yugo Nagata
Reviewed-by: FabrÃzio de Royes Mello
Discussion:
https://postgr.es/m/20250214010218.550ebe4ec1a7c7811a7fa2bb%40sraoss.co.jp
Branch
---
docs: EUC_TW can be up to four bytes wide, not three
Backpatch-through: 13
Security: CVE-2025-1094
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/9dc952d9a077d4c5407b2da751d2e985d83e4924
Modified Files
--
doc/src/sgml/charset.sgml | 2 +-
1 file
Fix type in test_escape test
On machines where char is unsigned this could lead to option parsing looping
endlessly. It's also too narrow a type on other hardware.
Found via Tom Lane's monitoring of the buildfarm.
Reported-by: Tom Lane
Security: CVE-2025-1094
Backpatch-through: 13
Branch
-
Last-minute updates for release notes.
Security: CVE-2025-1094
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/fa3ddd2ea8d62518f1f523027c55655856d5cc39
Modified Files
--
doc/src/sgml/release-13.sgml | 97 ++
Fix handling of invalidly encoded data in escaping functions
Previously invalidly encoded input to various escaping functions could lead to
the escaped string getting incorrectly parsed by psql. To be safe, escaping
functions need to ensure that neither invalid nor incomplete multi-byte
character
Add test of various escape functions
As highlighted by the prior commit, writing correct escape functions is less
trivial than one might hope.
This test module tries to verify that different escaping functions behave
reasonably. It e.g. tests:
- Invalidly encoded input to an escape function lead
Adapt appendPsqlMetaConnect() to the new fmtId() encoding expectations.
We need to tell fmtId() what encoding to assume, but this function
doesn't know that. Fortunately we can fix that without changing the
function's API, because we can just use SQL_ASCII. That's because
database names in conne
Fix type in test_escape test
On machines where char is unsigned this could lead to option parsing looping
endlessly. It's also too narrow a type on other hardware.
Found via Tom Lane's monitoring of the buildfarm.
Reported-by: Tom Lane
Security: CVE-2025-1094
Backpatch-through: 13
Branch
-
Last-minute updates for release notes.
Security: CVE-2025-1094
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/7e06ffbc6230a6f3e4cdc7599a5617d081d611f7
Modified Files
--
doc/src/sgml/release-16.sgml | 96 ++
Adapt appendPsqlMetaConnect() to the new fmtId() encoding expectations.
We need to tell fmtId() what encoding to assume, but this function
doesn't know that. Fortunately we can fix that without changing the
function's API, because we can just use SQL_ASCII. That's because
database names in conne
Last-minute updates for release notes.
Security: CVE-2025-1094
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/1c77ff9f9a0278bb23b3629417ed7ce097c1697a
Modified Files
--
doc/src/sgml/release-15.sgml | 96 ++
Fix type in test_escape test
On machines where char is unsigned this could lead to option parsing looping
endlessly. It's also too narrow a type on other hardware.
Found via Tom Lane's monitoring of the buildfarm.
Reported-by: Tom Lane
Security: CVE-2025-1094
Backpatch-through: 13
Branch
-
Last-minute updates for release notes.
Security: CVE-2025-1094
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/e748064669f40a2dc9cf29b8518902620e47e2db
Modified Files
--
doc/src/sgml/release-14.sgml | 96 ++
Last-minute updates for release notes.
Security: CVE-2025-1094
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/1ea6e890b225fa45911f58602b8c425ae0581897
Modified Files
--
doc/src/sgml/release-17.sgml | 96 ++
Fix type in test_escape test
On machines where char is unsigned this could lead to option parsing looping
endlessly. It's also too narrow a type on other hardware.
Found via Tom Lane's monitoring of the buildfarm.
Reported-by: Tom Lane
Security: CVE-2025-1094
Backpatch-through: 13
Branch
-
Fix type in test_escape test
On machines where char is unsigned this could lead to option parsing looping
endlessly. It's also too narrow a type on other hardware.
Found via Tom Lane's monitoring of the buildfarm.
Reported-by: Tom Lane
Security: CVE-2025-1094
Backpatch-through: 13
Branch
-
Adapt appendPsqlMetaConnect() to the new fmtId() encoding expectations.
We need to tell fmtId() what encoding to assume, but this function
doesn't know that. Fortunately we can fix that without changing the
function's API, because we can just use SQL_ASCII. That's because
database names in conne
Adapt appendPsqlMetaConnect() to the new fmtId() encoding expectations.
We need to tell fmtId() what encoding to assume, but this function
doesn't know that. Fortunately we can fix that without changing the
function's API, because we can just use SQL_ASCII. That's because
database names in conne
Adapt appendPsqlMetaConnect() to the new fmtId() encoding expectations.
We need to tell fmtId() what encoding to assume, but this function
doesn't know that. Fortunately we can fix that without changing the
function's API, because we can just use SQL_ASCII. That's because
database names in conne
Add test of various escape functions
As highlighted by the prior commit, writing correct escape functions is less
trivial than one might hope.
This test module tries to verify that different escaping functions behave
reasonably. It e.g. tests:
- Invalidly encoded input to an escape function lead
Adapt appendPsqlMetaConnect() to the new fmtId() encoding expectations.
We need to tell fmtId() what encoding to assume, but this function
doesn't know that. Fortunately we can fix that without changing the
function's API, because we can just use SQL_ASCII. That's because
database names in conne
Fix handling of invalidly encoded data in escaping functions
Previously invalidly encoded input to various escaping functions could lead to
the escaped string getting incorrectly parsed by psql. To be safe, escaping
functions need to ensure that neither invalid nor incomplete multi-byte
character
Fix type in test_escape test
On machines where char is unsigned this could lead to option parsing looping
endlessly. It's also too narrow a type on other hardware.
Found via Tom Lane's monitoring of the buildfarm.
Reported-by: Tom Lane
Security: CVE-2025-1094
Backpatch-through: 13
Branch
-
Specify the encoding of input to fmtId()
This commit adds fmtIdEnc() and fmtQualifiedIdEnc(), which allow to specify
the encoding as an explicit argument. Additionally setFmtEncoding() is
provided, which defines the encoding when no explicit encoding is provided, to
avoid breaking all code using
Add pg_encoding_set_invalid()
There are cases where we cannot / do not want to error out for invalidly
encoded input. In such cases it can be useful to replace e.g. an incomplete
multi-byte characters with bytes that will trigger an error when getting
validated as part of a larger string.
Unfortu
Add test of various escape functions
As highlighted by the prior commit, writing correct escape functions is less
trivial than one might hope.
This test module tries to verify that different escaping functions behave
reasonably. It e.g. tests:
- Invalidly encoded input to an escape function lead
docs: EUC_TW can be up to four bytes wide, not three
Backpatch-through: 13
Security: CVE-2025-1094
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/dd3c1eb38e9add293f8be59b6aec7574e8584bdb
Modified Files
--
doc/src/sgml/charset.sgml | 2 +-
1 file
Add pg_encoding_set_invalid()
There are cases where we cannot / do not want to error out for invalidly
encoded input. In such cases it can be useful to replace e.g. an incomplete
multi-byte characters with bytes that will trigger an error when getting
validated as part of a larger string.
Unfortu
Add pg_encoding_set_invalid()
There are cases where we cannot / do not want to error out for invalidly
encoded input. In such cases it can be useful to replace e.g. an incomplete
multi-byte characters with bytes that will trigger an error when getting
validated as part of a larger string.
Unfortu
Fix handling of invalidly encoded data in escaping functions
Previously invalidly encoded input to various escaping functions could lead to
the escaped string getting incorrectly parsed by psql. To be safe, escaping
functions need to ensure that neither invalid nor incomplete multi-byte
character
docs: EUC_TW can be up to four bytes wide, not three
Backpatch-through: 13
Security: CVE-2025-1094
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/17b789469106e156f559fcdab0c720db3c38151a
Modified Files
--
doc/src/sgml/charset.sgml | 2 +-
1 file
Fix handling of invalidly encoded data in escaping functions
Previously invalidly encoded input to various escaping functions could lead to
the escaped string getting incorrectly parsed by psql. To be safe, escaping
functions need to ensure that neither invalid nor incomplete multi-byte
character
Add pg_encoding_set_invalid()
There are cases where we cannot / do not want to error out for invalidly
encoded input. In such cases it can be useful to replace e.g. an incomplete
multi-byte characters with bytes that will trigger an error when getting
validated as part of a larger string.
Unfortu
Specify the encoding of input to fmtId()
This commit adds fmtIdEnc() and fmtQualifiedIdEnc(), which allow to specify
the encoding as an explicit argument. Additionally setFmtEncoding() is
provided, which defines the encoding when no explicit encoding is provided, to
avoid breaking all code using
Add test of various escape functions
As highlighted by the prior commit, writing correct escape functions is less
trivial than one might hope.
This test module tries to verify that different escaping functions behave
reasonably. It e.g. tests:
- Invalidly encoded input to an escape function lead
docs: EUC_TW can be up to four bytes wide, not three
Backpatch-through: 13
Security: CVE-2025-1094
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/57bda2508f1c666fd18f2b233823b7c98308226b
Modified Files
--
doc/src/sgml/charset.sgml | 2 +-
1 file
Specify the encoding of input to fmtId()
This commit adds fmtIdEnc() and fmtQualifiedIdEnc(), which allow to specify
the encoding as an explicit argument. Additionally setFmtEncoding() is
provided, which defines the encoding when no explicit encoding is provided, to
avoid breaking all code using
Specify the encoding of input to fmtId()
This commit adds fmtIdEnc() and fmtQualifiedIdEnc(), which allow to specify
the encoding as an explicit argument. Additionally setFmtEncoding() is
provided, which defines the encoding when no explicit encoding is provided, to
avoid breaking all code using
Add pg_encoding_set_invalid()
There are cases where we cannot / do not want to error out for invalidly
encoded input. In such cases it can be useful to replace e.g. an incomplete
multi-byte characters with bytes that will trigger an error when getting
validated as part of a larger string.
Unfortu
Specify the encoding of input to fmtId()
This commit adds fmtIdEnc() and fmtQualifiedIdEnc(), which allow to specify
the encoding as an explicit argument. Additionally setFmtEncoding() is
provided, which defines the encoding when no explicit encoding is provided, to
avoid breaking all code using
Add pg_encoding_set_invalid()
There are cases where we cannot / do not want to error out for invalidly
encoded input. In such cases it can be useful to replace e.g. an incomplete
multi-byte characters with bytes that will trigger an error when getting
validated as part of a larger string.
Unfortu
docs: EUC_TW can be up to four bytes wide, not three
Backpatch-through: 13
Security: CVE-2025-1094
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/32c34006b24bf7432c2d0f47da10492de7253d52
Modified Files
--
doc/src/sgml/charset.sgml | 2 +-
1 file changed
Back-patch pg_encoding_verifymbstr()/pg_encoding_verifymbchar() to v13.
A security fix will need those functions, so back-patch the v14+ functions to
v13.
When commit b80e10638e36b9d2f0b39170c613837af2ca2aac introduced the v14+
implementation of pg_encoding_verifymbstr(), it added a callback to e
docs: EUC_TW can be up to four bytes wide, not three
Backpatch-through: 13
Security: CVE-2025-1094
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/16ce519533bd03db726953db2364877a8944da4c
Modified Files
--
doc/src/sgml/charset.sgml | 2 +-
1 file
Fix handling of invalidly encoded data in escaping functions
Previously invalidly encoded input to various escaping functions could lead to
the escaped string getting incorrectly parsed by psql. To be safe, escaping
functions need to ensure that neither invalid nor incomplete multi-byte
character
Fix handling of invalidly encoded data in escaping functions
Previously invalidly encoded input to various escaping functions could lead to
the escaped string getting incorrectly parsed by psql. To be safe, escaping
functions need to ensure that neither invalid nor incomplete multi-byte
character
Add test of various escape functions
As highlighted by the prior commit, writing correct escape functions is less
trivial than one might hope.
This test module tries to verify that different escaping functions behave
reasonably. It e.g. tests:
- Invalidly encoded input to an escape function lead
Add test of various escape functions
As highlighted by the prior commit, writing correct escape functions is less
trivial than one might hope.
This test module tries to verify that different escaping functions behave
reasonably. It e.g. tests:
- Invalidly encoded input to an escape function lead
Specify the encoding of input to fmtId()
This commit adds fmtIdEnc() and fmtQualifiedIdEnc(), which allow to specify
the encoding as an explicit argument. Additionally setFmtEncoding() is
provided, which defines the encoding when no explicit encoding is provided, to
avoid breaking all code using
Remove unnecessary (char *) casts [xlog]
Remove (char *) casts no longer needed after XLogRegisterData() and
XLogRegisterBufData() argument type change.
Reviewed-by: Dagfinn Ilmari Mannsåker
Discussion:
https://www.postgresql.org/message-id/flat/fd1fcedb-3492-4fc8-9e3e-74b97f2db6c7%40eisentraut
XLogRegisterData, XLogRegisterBufData void * argument for binary data
Change XLogRegisterData() and XLogRegisterBufData() functions to take
void * for binary data instead of char *. This will remove the need
for numerous casts (done in a separate commit for clarity).
Reviewed-by: Dagfinn Ilmari
52 matches
Mail list logo
