ides that the failures started earlier.
What it looks like from here is that Andres messed up the
installed-packages set on a lot of his animals.
regards, tom lane
Remove race conditions between ECPGdebug() and ecpg_log().
Coverity complains that ECPGdebug is accessing debugstream without
holding debug_mutex, which is a fair complaint: we should take
debug_mutex while changing the settings ecpg_log looks at.
In some branches it also complains about
Remove race conditions between ECPGdebug() and ecpg_log().
Coverity complains that ECPGdebug is accessing debugstream without
holding debug_mutex, which is a fair complaint: we should take
debug_mutex while changing the settings ecpg_log looks at.
In some branches it also complains about
Remove race conditions between ECPGdebug() and ecpg_log().
Coverity complains that ECPGdebug is accessing debugstream without
holding debug_mutex, which is a fair complaint: we should take
debug_mutex while changing the settings ecpg_log looks at.
In some branches it also complains about
Remove race conditions between ECPGdebug() and ecpg_log().
Coverity complains that ECPGdebug is accessing debugstream without
holding debug_mutex, which is a fair complaint: we should take
debug_mutex while changing the settings ecpg_log looks at.
In some branches it also complains about
Remove race conditions between ECPGdebug() and ecpg_log().
Coverity complains that ECPGdebug is accessing debugstream without
holding debug_mutex, which is a fair complaint: we should take
debug_mutex while changing the settings ecpg_log looks at.
In some branches it also complains about
Remove race conditions between ECPGdebug() and ecpg_log().
Coverity complains that ECPGdebug is accessing debugstream without
holding debug_mutex, which is a fair complaint: we should take
debug_mutex while changing the settings ecpg_log looks at.
In some branches it also complains about
Fix input of ISO "extended" time format for types time and timetz.
Commit 3e1a373e2 missed teaching DecodeTimeOnly the same "ptype"
manipulations it added to DecodeDateTime. While likely harmless
at the time, it became a problem after 5b3c59535 added an error check
that ptype must be zero once
Fix input of ISO "extended" time format for types time and timetz.
Commit 3e1a373e2 missed teaching DecodeTimeOnly the same "ptype"
manipulations it added to DecodeDateTime. While likely harmless
at the time, it became a problem after 5b3c59535 added an error check
that ptype must be zero once
Fix handling of extended expression statistics in CREATE TABLE LIKE.
transformTableLikeClause believed that it could process extended
statistics immediately because "the representation of CreateStatsStmt
doesn't depend on column numbers". That was true when extended stats
were first introduced,
Fix handling of extended expression statistics in CREATE TABLE LIKE.
transformTableLikeClause believed that it could process extended
statistics immediately because "the representation of CreateStatsStmt
doesn't depend on column numbers". That was true when extended stats
were first introduced,
Fix handling of extended expression statistics in CREATE TABLE LIKE.
transformTableLikeClause believed that it could process extended
statistics immediately because "the representation of CreateStatsStmt
doesn't depend on column numbers". That was true when extended stats
were first introduced,
Fix handling of extended expression statistics in CREATE TABLE LIKE.
transformTableLikeClause believed that it could process extended
statistics immediately because "the representation of CreateStatsStmt
doesn't depend on column numbers". That was true when extended stats
were first introduced,
Stamp 17beta1.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/86a2d2a321215797abd1c67d9f2c52510423a97a
Modified Files
--
configure| 18 +-
configure.ac | 2 +-
meson.build | 2 +-
3 files changed, 11 insertions(+), 11 deletions(-)
Doc: remove 66c0185a3 from release notes.
Discussion: https://postgr.es/m/zktzf926vslr3...@depesz.com
(also some private discussion among pgsql-release)
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/e1e83a71715f1c2f0717bb66e630ca3bda79b9c1
Modified Files
Revert commit 66c0185a3 and follow-on patches.
This reverts 66c0185a3 (Allow planner to use Merge Append to
efficiently implement UNION) as well as the follow-on commits
d5d2205c8, 3b1a7eb28, 7487044d6. In addition to those, 07746a8ef
had to be removed then re-applied in a different place,
Account for optimized MinMax aggregates during SS_finalize_plan.
We are capable of optimizing MIN() and MAX() aggregates on indexed
columns into subqueries that exploit the index, rather than the normal
thing of scanning the whole table. When we do this, we replace the
Aggref node(s) with Params
Account for optimized MinMax aggregates during SS_finalize_plan.
We are capable of optimizing MIN() and MAX() aggregates on indexed
columns into subqueries that exploit the index, rather than the normal
thing of scanning the whole table. When we do this, we replace the
Aggref node(s) with Params
Account for optimized MinMax aggregates during SS_finalize_plan.
We are capable of optimizing MIN() and MAX() aggregates on indexed
columns into subqueries that exploit the index, rather than the normal
thing of scanning the whole table. When we do this, we replace the
Aggref node(s) with Params
Account for optimized MinMax aggregates during SS_finalize_plan.
We are capable of optimizing MIN() and MAX() aggregates on indexed
columns into subqueries that exploit the index, rather than the normal
thing of scanning the whole table. When we do this, we replace the
Aggref node(s) with Params
Account for optimized MinMax aggregates during SS_finalize_plan.
We are capable of optimizing MIN() and MAX() aggregates on indexed
columns into subqueries that exploit the index, rather than the normal
thing of scanning the whole table. When we do this, we replace the
Aggref node(s) with Params
Add test case showing that commit d0d44049d fixed a live bug.
When I committed d0d44049d (Account for optimized MinMax aggregates
during SS_finalize_plan), I didn't have a test case showing that it
was fixing any reachable bug. Here is one, based on bug #18465 from
Hal Takahara. Without the
Sync typedefs.list with buildfarm, for real this time.
In commit da256a4a7, I manually added some typedef names to the
buildfarm-generated list so as not to cause any formatting regressions
compared to the prior manually-updated list.
About half of the additions were injection-point-related
Doc: update src/tools/pgindent/README for current practice.
This README explains how to run pgindent, but it was written
for our former practice of running pgindent only infrequently.
Nowadays the plan is to keep the tree indent-clean all the time,
so the typical thing is to do an incremental
Fix handling of polymorphic output arguments for procedures.
Most of the infrastructure for procedure arguments was already
okay with polymorphic output arguments, but it turns out that
CallStmtResultDesc() was a few bricks shy of a load here. It thought
all it needed to do was call
Fix handling of polymorphic output arguments for procedures.
Most of the infrastructure for procedure arguments was already
okay with polymorphic output arguments, but it turns out that
CallStmtResultDesc() was a few bricks shy of a load here. It thought
all it needed to do was call
Fix handling of polymorphic output arguments for procedures.
Most of the infrastructure for procedure arguments was already
okay with polymorphic output arguments, but it turns out that
CallStmtResultDesc() was a few bricks shy of a load here. It thought
all it needed to do was call
Fix handling of polymorphic output arguments for procedures.
Most of the infrastructure for procedure arguments was already
okay with polymorphic output arguments, but it turns out that
CallStmtResultDesc() was a few bricks shy of a load here. It thought
all it needed to do was call
Fix handling of polymorphic output arguments for procedures.
Most of the infrastructure for procedure arguments was already
okay with polymorphic output arguments, but it turns out that
CallStmtResultDesc() was a few bricks shy of a load here. It thought
all it needed to do was call
Fix handling of polymorphic output arguments for procedures.
Most of the infrastructure for procedure arguments was already
okay with polymorphic output arguments, but it turns out that
CallStmtResultDesc() was a few bricks shy of a load here. It thought
all it needed to do was call
Do pre-release housekeeping on catalog data.
Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta
tasks specified by RELEASE_CHANGES. For reference, the command was
./renumber_oids.pl --first-mapped-oid 8000 --target-oid 6300
Branch
--
master
Details
---
Add da256a4a7 to .git-blame-ignore-revs.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ce13f54e6055d24e21cc969f498f121c37616921
Modified Files
--
.git-blame-ignore-revs | 3 +++
1 file changed, 3 insertions(+)
Pre-beta mechanical code beautification.
Run pgindent, pgperltidy, and reformat-dat-files.
The pgindent part of this is pretty small, consisting mainly of
fixing up self-inflicted formatting damage from patches that
hadn't bothered to add their new typedefs to typedefs.list.
In order to keep it
Remove COMMAND_TAG_NEXTTAG from enum CommandTag.
COMMAND_TAG_NEXTTAG isn't really a valid command tag. Declaring it
as if it were one prompts complaints from Coverity and perhaps other
static analyzers. Our only use of it is in an entirely-unnecessary
array sizing declaration, so let's just
Doc: update the "Using EXPLAIN" examples to match current code.
A lot of the examples in this section are quite ancient and no
longer match the system's current behavior. I ran through them
and updated the sample output to match what I get today.
Notably, it seems that the tenk1 table got a few
Last-minute updates for release notes.
Security: CVE-2024-4317
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/7b2ac0f6039f0f64d80c7488f0f718094cfb89a2
Modified Files
--
doc/src/sgml/release-15.sgml | 95
Last-minute updates for release notes.
Security: CVE-2024-4317
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/a62be834aeb899dfc2e10e3cde6d0f48ba128373
Modified Files
--
doc/src/sgml/release-16.sgml | 95
Last-minute updates for release notes.
Security: CVE-2024-4317
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/b7712704f0bb3dc82f286516a7057b0fa5b1d260
Modified Files
--
doc/src/sgml/release-14.sgml | 95
Fix recursive RECORD-returning plpython functions.
If we recursed to a new call of the same function, with a different
coldeflist (AS clause), it would fail because the inner call would
overwrite the outer call's idea of what to return. This is vaguely
like 1d2fe56e4 and c5bec5426, but it's not
Fix recursive RECORD-returning plpython functions.
If we recursed to a new call of the same function, with a different
coldeflist (AS clause), it would fail because the inner call would
overwrite the outer call's idea of what to return. This is vaguely
like 1d2fe56e4 and c5bec5426, but it's not
Fix recursive RECORD-returning plpython functions.
If we recursed to a new call of the same function, with a different
coldeflist (AS clause), it would fail because the inner call would
overwrite the outer call's idea of what to return. This is vaguely
like 1d2fe56e4 and c5bec5426, but it's not
Fix recursive RECORD-returning plpython functions.
If we recursed to a new call of the same function, with a different
coldeflist (AS clause), it would fail because the inner call would
overwrite the outer call's idea of what to return. This is vaguely
like 1d2fe56e4 and c5bec5426, but it's not
Fix recursive RECORD-returning plpython functions.
If we recursed to a new call of the same function, with a different
coldeflist (AS clause), it would fail because the inner call would
overwrite the outer call's idea of what to return. This is vaguely
like 1d2fe56e4 and c5bec5426, but it's not
Fix recursive RECORD-returning plpython functions.
If we recursed to a new call of the same function, with a different
coldeflist (AS clause), it would fail because the inner call would
overwrite the outer call's idea of what to return. This is vaguely
like 1d2fe56e4 and c5bec5426, but it's not
Repair ALTER EXTENSION ... SET SCHEMA.
It turns out that we broke this in commit e5bc9454e, because
the code was assuming that no dependent types would appear
among the extension's direct dependencies, and now they do.
This isn't terribly hard to fix: just skip dependent types,
expecting that we
, but I've refrained for now.)
This bug was exposed by the recent invention of REALLOCATE_BITMAPSETS.
Commit e0477837c had installed a fix, but that went away with the
reversion of SJE, so now we need to fix it again.
David Rowley and Tom Lane
Discussion:
https://postgr.es/m/CACJufxFVQmr4
. Add a para to the Triggers chapter to explain it.
Laurenz Albe, David Johnston, Tom Lane
Discussion:
https://postgr.es/m/b81fe38fcc25a81be6e2e5b3fc1ff624130762fa.ca...@cybertec.at
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff
Ensure that "pg_restore -l" reports dependent TOC entries correctly.
If -l was specified together with selective-restore options such as -n
or -N, dependent TOC entries such as comments would be omitted from
the listing, even when an actual restore would have selected them.
This happened because
Ensure that "pg_restore -l" reports dependent TOC entries correctly.
If -l was specified together with selective-restore options such as -n
or -N, dependent TOC entries such as comments would be omitted from
the listing, even when an actual restore would have selected them.
This happened because
Ensure that "pg_restore -l" reports dependent TOC entries correctly.
If -l was specified together with selective-restore options such as -n
or -N, dependent TOC entries such as comments would be omitted from
the listing, even when an actual restore would have selected them.
This happened because
Ensure that "pg_restore -l" reports dependent TOC entries correctly.
If -l was specified together with selective-restore options such as -n
or -N, dependent TOC entries such as comments would be omitted from
the listing, even when an actual restore would have selected them.
This happened because
Ensure that "pg_restore -l" reports dependent TOC entries correctly.
If -l was specified together with selective-restore options such as -n
or -N, dependent TOC entries such as comments would be omitted from
the listing, even when an actual restore would have selected them.
This happened because
Ensure that "pg_restore -l" reports dependent TOC entries correctly.
If -l was specified together with selective-restore options such as -n
or -N, dependent TOC entries such as comments would be omitted from
the listing, even when an actual restore would have selected them.
This happened because
Don't corrupt plpython's "TD" dictionary in a recursive trigger call.
If a plpython-language trigger caused another one to be invoked,
the "TD" dictionary created for the inner one would overwrite the
outer one's "TD" dictionary. This is more or less the same problem
that 1d2fe56e4 fixed for
Don't corrupt plpython's "TD" dictionary in a recursive trigger call.
If a plpython-language trigger caused another one to be invoked,
the "TD" dictionary created for the inner one would overwrite the
outer one's "TD" dictionary. This is more or less the same problem
that 1d2fe56e4 fixed for
Don't corrupt plpython's "TD" dictionary in a recursive trigger call.
If a plpython-language trigger caused another one to be invoked,
the "TD" dictionary created for the inner one would overwrite the
outer one's "TD" dictionary. This is more or less the same problem
that 1d2fe56e4 fixed for
Don't corrupt plpython's "TD" dictionary in a recursive trigger call.
If a plpython-language trigger caused another one to be invoked,
the "TD" dictionary created for the inner one would overwrite the
outer one's "TD" dictionary. This is more or less the same problem
that 1d2fe56e4 fixed for
Don't corrupt plpython's "TD" dictionary in a recursive trigger call.
If a plpython-language trigger caused another one to be invoked,
the "TD" dictionary created for the inner one would overwrite the
outer one's "TD" dictionary. This is more or less the same problem
that 1d2fe56e4 fixed for
Don't corrupt plpython's "TD" dictionary in a recursive trigger call.
If a plpython-language trigger caused another one to be invoked,
the "TD" dictionary created for the inner one would overwrite the
outer one's "TD" dictionary. This is more or less the same problem
that 1d2fe56e4 fixed for
Prevent RLS filters on ctid from breaking WHERE CURRENT OF .
The executor only supports CurrentOfExpr as the sole tidqual of a
TidScan plan node. tidpath.c failed to take any particular care about
that, but would just take the first ctid equality qual it could find
in the target relation's
Stamp 12.19.
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/01aeb431c12a3388594a445ca97e71cbed410ed2
Modified Files
--
configure| 18 +-
configure.in | 2 +-
Stamp 13.15.
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/8e5faba4b918ba6142339c8f55eaa4eb99776a03
Modified Files
--
configure| 18 +-
configure.in | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
Stamp 14.12.
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/cf07a47dc0c3b16778291e62d730537b45da51ef
Modified Files
--
configure| 18 +-
configure.ac | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
Stamp 15.7.
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/4a53584cf2d676e685d899d01cde18c075fbeca7
Modified Files
--
configure| 18 +-
configure.ac | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
Stamp 16.3.
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/05ffe9398b758bbb8d30cc76e9bbc638dab2d477
Modified Files
--
configure| 18 +-
configure.ac | 2 +-
meson.build | 2 +-
3 files changed, 11 insertions(+), 11
Finish incomplete revert of ec63622c0.
The code change this made might well be fine to keep, but the
comment justifying it by reference to self-join removal isn't.
Let's just go back to the status quo ante, pending a more thorough
review/redesign of SJE.
(I found this by grepping to see if any
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/9fc09cc294ff9fcf961758bf4d020c9899c4af13
Modified Files
--
doc/src/sgml/release-16.sgml | 18 --
1 file changed, 18 deletions(-)
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/1272af45d6230803eb1cf03a84b98fd6c4173a9f
Modified Files
--
doc/src/sgml/release-12.sgml | 806 +++
1 file
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/ac7049dbf33943d5ecbadfdb0f2091fa4ff88748
Modified Files
--
doc/src/sgml/release-15.sgml | 1108 ++
1 file
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/6cb4d1d486220c8e194009466ea5a25108afb19c
Modified Files
--
doc/src/sgml/release-14.sgml | 915 +++
1 file
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/2bfd5ea56edca1521404e180730d56fa4c379f27
Modified Files
--
doc/src/sgml/release-13.sgml | 800 +++
1 file
Silence Coverity complaint about possible null-pointer dereference.
If pg_init_privs were to contain a NULL ACL field, this code would
pass old_acl == NULL to merge_acl_with_grant, which would crash.
The case shouldn't happen, but it just takes a couple more lines
of code to guard against it, so
First-draft release notes for 16.3.
As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first.
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/7155cc4a60e7bfc837233b2dea2563a2edc673fd
Allow selecting the git revision to be packaged by "make dist".
Commit 619bc23a1 changed "make dist" to invoke "git archive",
but hard-wired the call to specify that the HEAD revision should
be packaged. Our tarball building process needs to be able to
specify which git commit to package
Throw a more on-point error for publications depending on columns.
Same as 42b041243, except that the trouble case is a publication
WHERE clause that depends on a column.
Again reported by Alexander Lakhin. Back-patch to v15 where
we added publication WHERE clauses.
Discussion:
Throw a more on-point error for publications depending on columns.
Same as 42b041243, except that the trouble case is a publication
WHERE clause that depends on a column.
Again reported by Alexander Lakhin. Back-patch to v15 where
we added publication WHERE clauses.
Discussion:
Throw a more on-point error for publications depending on columns.
Same as 42b041243, except that the trouble case is a publication
WHERE clause that depends on a column.
Again reported by Alexander Lakhin. Back-patch to v15 where
we added publication WHERE clauses.
Discussion:
ets. But we do have a history of posting corrections in this
mailing list, just in case future hackers want to track something
down.
regards, tom lane
Disallow converting a table to a view within an outer SQL command.
We have long disallowed all forms of ALTER TABLE if the table is
already opened by some outer SQL command in the same session.
This has the same purpose as obtaining AccessExclusiveLock, but
since a session's own locks don't
Disallow converting a table to a view within an outer SQL command.
We have long disallowed all forms of ALTER TABLE if the table is
already opened by some outer SQL command in the same session.
This has the same purpose as obtaining AccessExclusiveLock, but
since a session's own locks don't
Disallow converting a table to a view within an outer SQL command.
We have long disallowed all forms of ALTER TABLE if the table is
already opened by some outer SQL command in the same session.
This has the same purpose as obtaining AccessExclusiveLock, but
since a session's own locks don't
Disallow converting a table to a view within an outer SQL command.
We have long disallowed all forms of ALTER TABLE if the table is
already opened by some outer SQL command in the same session.
This has the same purpose as obtaining AccessExclusiveLock, but
since a session's own locks don't
Fix one more portability shortcoming in new test_pg_dump test.
If the bootstrap superuser's name requires quoting, regroleout
will supply double quotes ... but the result of CURRENT_USER
is just the literal name. Apply quote_ident() to ensure a match.
Per Andrew Dunstan's off-list investigation
Heikki Linnakangas writes:
> On 30/04/2024 02:32, Tom Lane wrote:
>> A moderately large fraction of the buildfarm doesn't seem to
>> recognize SSL_AD_NO_APPLICATION_PROTOCOL.
> *sigh*. I checked that it exists on OpenSSL 1.1.1, but according to
> buildfarm it's not pre
David Rowley writes:
> On Tue, 30 Apr 2024 at 14:14, Tom Lane wrote:
>> Yeah, the affected buildfarm members seem still not happy.
> Isn't your latest fix adding COLLATE "C" to the wrong test?
Oh! No, it was definitely adjusting a test that needed it,
just not the
Force COLLATE "C" to stabilize ordering, redux.
David Rowley correctly pointed out that I'd collat-ified only
one of the two troublesome queries. Definitely not my day.
Discussion:
https://postgr.es/m/caaphdvo8pmk5wwfaqwgzuq-xh+957w61io_oscp0ouzqcco...@mail.gmail.com
Branch
--
master
s the new test_pg_dump query, we are
somehow losing the COLLATE "C" specification --- it's there in the
Sort node according to EXPLAIN VERBOSE, but it sure doesn't seem to be
having any effect.
I'm too tired to look any closer tonight, though.
regards, tom lane
expected it to show up in other regression tests already.)
I'll await buildfarm results, but there's something odd here.
regards, tom lane
Force COLLATE "C" to stabilize ordering in new test_pg_dump queries.
Should have thought of the need for this.
(Local testing suggests that we may still not be out of the
woods, but certainly this much is needed.)
Per buildfarm and David Rowley.
Discussion:
David Rowley writes:
> Maybe:
> SELECT pg_describe_object(classid,objid,objsubid) COLLATE "C" AS obj,
Argh, I knew better than to not specify COLLATE "C".
This commit's feeling a little snakebit.
regards, tom lane
Fix test case from b0c5b215d.
I'd not checked that this iteration of the test actually worked
with a bootstrap superuser not named 'postgres'. It didn't,
because the coercion rules for CASE caused us to try to cast
the 'postgres' literal to regrole. Mea culpa.
Per buildfarm (via Alexander
in a few.
regards, tom lane
Allow meson builds to run test_pg_dump test in installcheck mode.
This had been disabled because the test "doesn't delete its user".
It doesn't seem like a great idea for the meson tests to act
differently from the makefile tests, though, and the makefiles
had no such exception (which is how come
Heikki Linnakangas writes:
> Reject SSL connection if ALPN is used but there's no common protocol
A moderately large fraction of the buildfarm doesn't seem to
recognize SSL_AD_NO_APPLICATION_PROTOCOL.
regards, tom lane
Fix failure to track role dependencies of pg_init_privs entries.
If an ACL recorded in pg_init_privs mentions a non-pinned role,
that reference must also be noted in pg_shdepend so that we know
that the role can't go away without removing the ACL reference.
Otherwise, DROP ROLE could succeed and
Throw a more on-point error for functions depending on columns.
ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects
depending on the column whose type is to be altered. That indeed
wasn't possible when this code was written, but it is possible
since we introduced new-style SQL
Throw a more on-point error for functions depending on columns.
ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects
depending on the column whose type is to be altered. That indeed
wasn't possible when this code was written, but it is possible
since we introduced new-style SQL
Throw a more on-point error for functions depending on columns.
ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects
depending on the column whose type is to be altered. That indeed
wasn't possible when this code was written, but it is possible
since we introduced new-style SQL
Throw a more on-point error for functions depending on columns.
ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects
depending on the column whose type is to be altered. That indeed
wasn't possible when this code was written, but it is possible
since we introduced new-style SQL
Detect more overflows in timestamp[tz]_pl_interval.
In commit 25cd2d640 I (tgl) opined that "The additions of the months
and microseconds fields could also overflow, of course. However,
I believe we need no additional checks there; the existing range
checks should catch such cases". This is
1 - 100 of 9721 matches
Mail list logo
