Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Fri, 23 May 2025 at 14:48, jian he wrote: > when you mark it as IMMUTABLE, postgres think it's IMMUTABLE, but in this case > exploit_generated.exploit(i int) clearly is not an IMMUTABLE function. > > Only IMMUTABLE functions are allowed in generated expressions, > but you can still misuse it by

Re: Random subscription 021_twophase test failure on kestrel

On Sat, May 24, 2025 at 6:07 AM Michael Paquier wrote: > > > Yes, agreed that your suggested fix looks sensible with an extra check > for pg_prepared_xacts on the subscriber side that can be useful for > debugging. > +1. -- With Regards, Amit Kapila.

Re: Conflict detection for update_deleted in logical replication

On Sat, May 24, 2025 at 10:29 AM Dilip Kumar wrote: > > On Sat, May 24, 2025 at 10:04 AM Dilip Kumar wrote: > > > > On Fri, May 23, 2025 at 9:21 PM Xuneng Zhou wrote: > > > > > Looking at v31-0001 again, most of it looks fine except this logic of > > getting the commit_ts after marking the trans

Re: Replication slot is not able to sync up

On Fri, May 23, 2025 at 11:25 PM Robert Haas wrote: > > On Fri, May 23, 2025 at 12:55 AM Amit Kapila wrote: > > The remote_slot (slot on primary) should be advanced before you invoke > > sync_slot. Can you do pg_logical_slot_get_changes() API before performing > > sync? You can check the xmin o

Re: Conflict detection for update_deleted in logical replication

On Sat, May 24, 2025 at 10:04 AM Dilip Kumar wrote: > > On Fri, May 23, 2025 at 9:21 PM Xuneng Zhou wrote: > > > Looking at v31-0001 again, most of it looks fine except this logic of > getting the commit_ts after marking the transaction in commit. I see > in RecordTransactionCommit(), we are set

Re: Conflict detection for update_deleted in logical replication

On Fri, May 23, 2025 at 9:21 PM Xuneng Zhou wrote: > Looking at v31-0001 again, most of it looks fine except this logic of getting the commit_ts after marking the transaction in commit. I see in RecordTransactionCommit(), we are setting this flag (DELAY_CHKPT_IN_COMMIT) to put the transaction in

Re: Covering the comparison between date and timestamp, tz, type

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hi Kwangwon, I have reviewed your patch. Funtions you menti

Re: Non-reproducible AIO failure

Alexander Lakhin writes: > FWIW, that Assert have just triggered on another mac: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=indri&dt=2025-05-23%2020%3A30%3A07 Yeah, I was just looking at that too. There is a corefile from that crash, but lldb seems unable to extract anything from

Re: Non-reproducible AIO failure

Hello Tom and Andres, 24.04.2025 01:58, Tom Lane wrote: Andres Freund writes: On 2025-04-23 17:17:01 -0400, Tom Lane wrote: My buildfarm animal sifaka just failed like this [1]: There's nothing really special about sifaka, is there? I see -std=gnu99 and a few debug -D cppflags, but they don'

Re: mention unused_oids script in pg_proc.dat

> > This stuff is already documented in bki.sgml. Adding an extra > location to hint about the script may be useful to have, but > pg_proc.dat is not a good choice as it is one catalog among many > others. One idea: we could add a README or a README.oid in > src/include/catalog/ telling more a

Re: Retiring some encodings?

> Yeah, that's a good point. I would also question what's the benefit > in using GB18030 over UTF-8, though. An obvious one I can see is > because legacy applications never get updated. Plus users have too many GB18030 encoded files, I guess. -- Tatsuo Ishii SRA OSS K.K. English: http://www.srao

Re: queryId constant squashing does not support prepared statements

On Fri, May 23, 2025 at 08:05:47PM -0500, Sami Imseih wrote: > Since we assign new parameter symbols based on the highest external param > from the original query, as stated in the docs [0] "The parameter > symbols used to replace > constants in representative query texts start from the next number

Re: queryId constant squashing does not support prepared statements

> On Fri, May 23, 2025 at 04:29:45PM +0200, Dmitry Dolgov wrote: > > I think it's better to recursively call IsSquashableConst on the nested > > expression (arg or args for FuncExpr). Something like that was done in > > the original patch version and was concidered too much at that time, but > > si

Fixing memory leaks in postgres_fdw

Running contrib/postgres_fdw's regression tests under Valgrind shows two different sources of memory leaks. One is a basically-cosmetic issue in InitPgFdwOptions, but the other is real and troublesome. The DirectModify code path relies on PG_TRY blocks to ensure that it releases the PGresult for t

Re: mention unused_oids script in pg_proc.dat

On Fri, May 23, 2025 at 07:03:31PM +0300, Florents Tselai wrote: > - For the sake of the archives: this has been mentioned on Discord. +++ b/src/include/catalog/pg_proc.dat +# To find unused OIDs see src/include/catalog/unused_oids. +# If multiple related OIDs are added, it is suggested they're c

Re: Random subscription 021_twophase test failure on kestrel

On Fri, May 23, 2025 at 08:55:27PM +0530, vignesh C wrote: > This issue can be consistently reproduced by injecting a delay (e.g., > 3 seconds) in tap_sub's walsender while decoding the commit of > 'mygid'. A patch to demonstrate this behavior is provided at > 021_two_phase_test_failure_reproduce.p

Re: queryId constant squashing does not support prepared statements

On Fri, May 23, 2025 at 04:29:45PM +0200, Dmitry Dolgov wrote: > I think it's better to recursively call IsSquashableConst on the nested > expression (arg or args for FuncExpr). Something like that was done in > the original patch version and was concidered too much at that time, but > since it loo

Re: Retiring some encodings?

On Fri, May 23, 2025 at 07:58:46PM +0900, Tatsuo Ishii wrote: > Another point is, whether other DBMS support GB18030 or not. If they > support, but PostgreSQL would not in the future, that could be a > reason to move away from PostgreSQL. Yeah, that's a good point. I would also question what's th

Re: PG 18 release notes draft committed

On Fri, May 23, 2025 at 04:01:41PM -0400, Bruce Momjian wrote: > I updated the release notes to current and included your patch, > attached, thanks. Just noticed 1ca583f6c0f9. Thanks for the commit. -- Michael signature.asc Description: PGP signature

Re: Addition of %b/backend_type in log_line_prefix of TAP test logs

On Fri, May 23, 2025 at 11:56:59PM +0900, Fujii Masao wrote: > On 2025/05/22 8:58, Tom Lane wrote: >> Michael Paquier writes: >>> Another point perhaps worth considering after a second look: how about >>> pg_ci_base.conf? We have the following line there, exposing this >>> configuration with TEMP

Re: pgsql: Make cancel request keys longer

On Thu, May 8, 2025 at 11:38 PM Heikki Linnakangas wrote: > It didn't occur to me that you could write it simply as 'msgLength - 4'. > That depends on knowing that the preceding fields are exactly 4 bytes > long, but that's clear enough if we just add a comment on that, see > attached. Sorry for

tighten generic_option_name, or store more carefully in catalog?

Hi, generic_option_name is a ColLabel, therefore a fully general SQL identifier. But a command like CREATE FOREIGN DATA WRAPPER w ... OPTIONS ("a=b" 'c=d') stores {a=b=c=d} in fdwoptions, from which the original intent can't be recovered. Should generic_option_name be restricted to be a regular

Re: [WIP]Vertical Clustered Index (columnar store extension) - take2

Hello Iwata-san, Thanks for presenting the patch at pgconf.dev last week, and for the discussions at the APFS session. As promised I did a quick review of the patch this week, trying to understand the design, the trade-offs etc. I'm still trying to understand the patch, so please correct me when

Re: Why our Valgrind reports suck

Here's a v3 patchset that's rebased up to HEAD (on top of the extracted fixes I already pushed) and responds to your review comments. I adopted your suggestions except for a couple: Andres Freund writes: > 0007: > + /* Run the rest in xact context to avoid Valgrind leak complaints */ > +

Re: Enable data checksums by default

On Fri, May 23, 2025 at 11:10:47AM +0300, Heikki Linnakangas wrote: > On 24/04/2025 14:26, Peter Eisentraut wrote: > > action for beta1 is (a).  And then for (c) perhaps monitor the feedback > > between beta1 and beta2. > > > > Ping: It's time to do something about this open item. (Or decide to d

Re: PG 18 release notes draft committed

On Fri, May 23, 2025 at 10:01:13AM -0400, Peter Geoghegan wrote: > On Thu, May 22, 2025 at 10:24 PM Bruce Momjian wrote: > > I see your point that we are not defining what this does. I went with > > the attached text. > > You propose the wording is "This allows muti-column btree indexes to > be

Re: Assert("vacrel->eager_scan_remaining_successes > 0")

On Fri, May 23, 2025 at 12:41 PM Masahiko Sawada wrote: > > I'll remove that part and push early next week, barring any objections. Great, thanks so much! - Melanie

Re: Understanding when VM record needs snapshot conflict horizon

On Fri, May 23, 2025 at 12:04 PM Andres Freund wrote: > > > 2) if our inclusion of a cutoff_xid when freezing tuples is what makes > > it safe to omit it from the VM update, then wouldn't that be true if > > we included a cutoff_xid when pruning a page in a way that rendered it > > all-visible too

Add CHECK_FOR_INTERRUPTS in polling loop code path in XactLockTableWait

Hi, While creating a logical replication slot, we wait for older transactions to complete to reach a "consistent point", which can take a while on busy databases. If we're creating a slot on a primary instance, it's pretty clear that we're waiting on a transaction: postgres=# SELECT pid,wait_eve

Re: PG 18 release notes draft committed

On Fri, May 23, 2025 at 03:16:51PM +0900, Michael Paquier wrote: > On Thu, May 01, 2025 at 10:44:50PM -0400, Bruce Momjian wrote: > > I will continue improving it until beta 1, and until the final release. > > I will probably add markup in 1-3 weeks. Let the feedback begin. ;-) > > May I sugges

Re: Replication slot is not able to sync up

On Fri, May 23, 2025 at 12:55 AM Amit Kapila wrote: > The remote_slot (slot on primary) should be advanced before you invoke > sync_slot. Can you do pg_logical_slot_get_changes() API before performing > sync? You can check the xmin of the logical slot after get_changes to ensure > that xmin has

Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part

Florents Tselai writes: > On 22 May 2025, at 11:56 PM, Peter Eisentraut wrote: >> I don't understand how this discussion got to the conclusion that functions >> that depend on the locale cannot be immutable. Note that the top-level >> functions lower, upper, and initcap themselves are immutabl

Re: Why our Valgrind reports suck

Peter Geoghegan writes: > On Fri, May 23, 2025 at 11:42 AM Andres Freund wrote: >>> I'm envisioning this patch series as v19 work, were you >>> thinking we should be more aggressive? >> Mostly agreed - but I am wondering if the AV fix should be backpatched? > I think that it probably should be.

Re: Fix slot synchronization with two_phase decoding enabled

On Wed, May 21, 2025 at 4:02 PM Masahiko Sawada wrote: > > On Fri, May 9, 2025 at 5:09 AM Nisha Moond wrote: > > > > On Thu, May 8, 2025 at 11:35 AM shveta malik wrote: > > > > > > On Wed, May 7, 2025 at 4:36 PM Nisha Moond > > > wrote: > > > > > > > > > > > > Attached is the v13 patch with th

Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part

> On 22 May 2025, at 11:56 PM, Peter Eisentraut wrote: > > On 09.05.25 21:50, Robert Haas wrote: >> I always struggle a bit to remember our policy on these issues -- to >> the best of my knowledge, we haven't documented it anywhere, and I >> think we probably should. I believe the way it works

Re: Assert("vacrel->eager_scan_remaining_successes > 0")

On Thu, May 22, 2025 at 1:19 PM Melanie Plageman wrote: > > On Thu, May 22, 2025 at 4:07 PM Masahiko Sawada wrote: > > > > Agreed. I've updated the patch. Does this address your comments? > > Yep. LGTM. > > I'd probably just remove the parenthetical remark about 20% from the > commit message sinc

Re: Understanding when VM record needs snapshot conflict horizon

Hi, On 2025-05-22 18:15:35 -0400, Melanie Plageman wrote: > I'm trying to understand when the visibility map WAL record > (xl_heap_visible) needs to include a snapshot conflict horizon. It needs to be included whenever replaying the WAL record could "break" an existing snapshot on the standby. E

mention unused_oids script in pg_proc.dat

- Cheers, Flo tselai.com Let's talk ☕ v1-0001-Add-pg_proc.dat-comment-mentioning-the-unused_oid.patch Description: Binary data

Re: Conflict detection for update_deleted in logical replication

Hi Zhijie, Thanks for the effort on the patches. I did a quick look on them before diving into the logic and discussion. Below are a few minor typos found in version 31. ⸻ 1. Spelling of “non-removable” [PATCH v31 1/7] In docs and code “removeable” vs. “removable” are used alternatively

Re: Why our Valgrind reports suck

On Fri, May 23, 2025 at 11:42 AM Andres Freund wrote: > > I'm envisioning this patch series as v19 work, were you > > thinking we should be more aggressive? > > Mostly agreed - but I am wondering if the AV fix should be backpatched? I think that it probably should be. -- Peter Geoghegan

Re: Why our Valgrind reports suck

Hi, On 2025-05-22 21:48:24 -0400, Tom Lane wrote: > Andres Freund writes: > >> But this is the last step to get to zero reported leaks in a run of the > >> core > >> regression tests, so let's do it. > > > I assume that's just about the core tests, not more? I.e. I can't make skink > > enable l

Random subscription 021_twophase test failure on kestrel

Hi, The 021_twophase test has failed on Kestrel at [1] with the following error: # Failed test 'should be no prepared transactions on subscriber' # at /home/bf/bf-build/kestrel/HEAD/pgsql/src/test/subscription/t/021_twophase.pl line 438. # got: '1' # expected: '0' # Looks like yo

Re: Addition of %b/backend_type in log_line_prefix of TAP test logs

On 2025/05/22 8:58, Tom Lane wrote: Michael Paquier writes: On Wed, May 21, 2025 at 09:24:26AM +0200, Daniel Gustafsson wrote: Agreed, and +1 on the change in general. Another point perhaps worth considering after a second look: how about pg_ci_base.conf? We have the following line ther

Re: [Util] Warn and Remove Invalid GUCs

Hi Greg, > Well, we do have ways to view all *potential* extensions. I find myself more > sympathetic to the OP than the others here, as I think it's a good idea to > display a warning for a potentially misspelled GUC prefix (but do nothing > else - certainly not remove it!).  I'm really glad

Re: Prevent an error on attaching/creating a DSM/DSA from an interrupt handler.

> On 20 May 2025, at 11:56, Daniel Gustafsson wrote: > >> On 20 May 2025, at 04:29, Tom Lane wrote: > >> I want to argue for reverting, at least for v18. I do not think that >> ProcessGetMemoryContextInterrupt is anywhere near release-quality. >> I found out while poking into Valgrind leak rep

Re: [Util] Warn and Remove Invalid GUCs

Hi Robert, > I think you might be missing the point of the comments from Tom and > David. To the extent that it is possible to give warnings, we already > do. So this proposal just doesn't really make sense. It either warns > in cases where there is no actual problem, or it gives a duplicate

Re: queryId constant squashing does not support prepared statements

> On Fri, May 23, 2025 at 09:05:54AM GMT, Sami Imseih wrote: > > > On Thu, May 22, 2025 at 10:23:31PM GMT, Sami Imseih wrote: > > > > This does not get squashed: > > > > Q: select where 2 in (1, 4) and > > > > 1 in (5, cast(7 as int), 6, (cast(8 as int)), 9, 10, (cast(8 as > > > > text))::int); >

Re: PG 18 release notes draft committed

On Thu, May 22, 2025 at 10:24 PM Bruce Momjian wrote: > I see your point that we are not defining what this does. I went with > the attached text. You propose the wording is "This allows muti-column btree indexes to be used by queries that only reference the second or later indexed columns". I

Re: queryId constant squashing does not support prepared statements

> > On Thu, May 22, 2025 at 10:23:31PM GMT, Sami Imseih wrote: > > > This does not get squashed: > > > Q: select where 2 in (1, 4) and > > > 1 in (5, cast(7 as int), 6, (cast(8 as int)), 9, 10, (cast(8 as > > > text))::int); > > > R: select where $1 in ($2 /*, ... */) and > > > $3 in ($4, cast($5

Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part

On Thu, May 22, 2025 at 4:56 PM Peter Eisentraut wrote: > I don't understand how this discussion got to the conclusion that > functions that depend on the locale cannot be immutable. Note that the > top-level functions lower, upper, and initcap themselves are immutable. Oh, well that was what To

Re: PG 18 release notes draft committed

On Fri, May 23, 2025 at 09:54:54AM +0200, Álvaro Herrera wrote: > On 2025-May-20, Bruce Momjian wrote: > > > On Tue, May 20, 2025 at 05:15:54PM +0300, Nazir Bilal Yavuz wrote: > > > > As of the date of the commit, "Co-authored-by:" is listed as: > > > > > > > > https://wiki.postgresql.org/

Re: PG 18 release notes draft committed

On Fri, May 23, 2025 at 10:46:09AM +0200, Álvaro Herrera wrote: > On 2025-May-22, Bruce Momjian wrote: > > > Ah, I see, fixed with the attached patch. It might be nice if we had a > > more organized way of recording such commit corrections. > > `git notes` can do that. They can also be used to

Disallow concurrent ALTER DOMAIN and DROP DOMAIN

hi similar to thread "Prevent internal error at concurrent CREATE OR REPLACE FUNCTION" [1]. We should prevent concurrent modifications to a domain's definition. Currently, it is possible for one session to drop a domain while another session simultaneously adds a constraint to it. It may result i

Re: Relstats after VACUUM FULL and CLUSTER

Hi Sami, Your patch should correct the problem. However, given that this function is part of the tableam API, I am wondering if the fix shouldn't be outside heap's copy_for_cluster implementation? I guess it depends on the semantics of num_tuples, but the cluster code seems to allude to interpreti

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Fri, May 23, 2025 at 4:43 PM Feike Steenbergen wrote: > > > Hi, > > While evaluating the PostgreSQL 18 beta, I had a thought experiment where I > thought it might be possible to use the new virtual generated columns to gain > superuser privileges for a regular user. > > Attached is a sample exp

Re: Enable data checksums by default

> On 23 May 2025, at 10:10, Heikki Linnakangas wrote: > Aside from just documenting it, I see two things we could do: > > 1. Have pg_upgrade run initdb for you. It's always felt silly that you need > to run initdb with the new version yourself, when there's really only one > correct way to do

Re: Update LDAP Protocol in fe-connect.c to v3

On 15.05.25 14:54, Pavel Seleznev wrote: I applied your patch. I ran extended application tests relative to vanilla ones, which include various scenarios of working with LDAP and I think that we can safely apply the patch in the PG18. I did not see the need for additional LDAP tests, since com

Re: Minor adjustment to pg_aios output naming

Anyway, thanks for the review! -- Atsushi Torikoshi

Re: Conflict detection for update_deleted in logical replication

On Thu, May 22, 2025 at 8:28 AM Zhijie Hou (Fujitsu) wrote: > > Attaching the V31 patch set which addressed comments in [1]~[8]. > Few comments: 1. + The oldest transaction ID along that is currently in the commit + phase on the server, along with its epoch. The first 'a

Re: Retiring some encodings?

>> On 23 May 2025, at 11:08, wenhui qiu wrote: >> >> HI >> > The obvious question is how many people would suffer because >> > of that removal, as it would prevent them from using pg_upgrade. >> >> > Can anybody who works in a region that uses these encodings make >> > an educated guess? >> +1

Re: Retiring some encodings?

> On 23 May 2025, at 11:08, wenhui qiu wrote: > > HI > > The obvious question is how many people would suffer because > > of that removal, as it would prevent them from using pg_upgrade. > > > Can anybody who works in a region that uses these encodings make > > an educated guess? > +1 Agree ,GB

Re: Enable data checksums by default

> On 23 May 2025, at 11:55, Tomas Vondra wrote: > > On 5/23/25 11:25, Daniel Gustafsson wrote: >>> On 23 May 2025, at 10:10, Heikki Linnakangas wrote: >> >>> Aside from just documenting it, I see two things we could do: >>> >>> 1. Have pg_upgrade run initdb for you. It's always felt silly that

Re: Enable data checksums by default

On 23.05.25 10:10, Heikki Linnakangas wrote: The point of the open item was (a) to make sure this is adequately documented, for instance in the release notes, (b) to think about technological solutions to simplify this, such as [0], and (c) to just check the general feedback. Nothing from [0]

Re: Enable data checksums by default

On 5/23/25 11:25, Daniel Gustafsson wrote: >> On 23 May 2025, at 10:10, Heikki Linnakangas wrote: > >> Aside from just documenting it, I see two things we could do: >> >> 1. Have pg_upgrade run initdb for you. It's always felt silly that you need >> to run initdb with the new version yourself, w

Re: Enable data checksums by default

On 5/23/25 11:22, Peter Eisentraut wrote: > On 23.05.25 10:10, Heikki Linnakangas wrote: >>> The point of the open item was (a) to make sure this is adequately >>> documented, for instance in the release notes, (b) to think about >>> technological solutions to simplify this, such as [0], and (c)

Re: RFC: Logging plan of the running query

On Fri, May 23, 2025 at 12:08 AM Robert Haas wrote: Thanks for your review! > On Tue, May 20, 2025 at 9:18 AM torikoshia wrote: > > I tackled this again and the attached patch removes ExecProcNodeOriginal > > from Planstate. > > Instead of adding a new field, this version builds the behavior int

Re: Retiring some encodings?

HI > The obvious question is how many people would suffer because > of that removal, as it would prevent them from using pg_upgrade. > Can anybody who works in a region that uses these encodings make > an educated guess? +1 Agree ,GB18030 A coding standard in China, if deleted, will have an impact

Re: Conflict detection for update_deleted in logical replication

On Fri, May 23, 2025 at 12:15 PM shveta malik wrote: > > Thanks you for v31 patch-set. Please find few comments on patch001: > > 1) > > wait_for_local_flush: > > + if (data->last_recv_time && > + TimestampDifferenceExceeds(data->flushpos_update_time, > +data->last_recv_time, WalWriterDelay)) >

Re: PG 18 release notes draft committed

On 2025-May-22, Bruce Momjian wrote: > Ah, I see, fixed with the attached patch. It might be nice if we had a > more organized way of recording such commit corrections. `git notes` can do that. They can also be used to indicate things such as commits being reverted. -- Álvaro Herrera

pg18: Virtual generated columns are not (yet) safe when superuser selects from them

Hi, While evaluating the PostgreSQL 18 beta, I had a thought experiment where I thought it might be possible to use the new virtual generated columns to gain superuser privileges for a regular user. Attached is a sample exploit, that achieves this, key components: - the GENERATED column uses a u

Re: Retiring some encodings?

> On 23 May 2025, at 09:18, Heikki Linnakangas wrote: > If we plan to remove something in the future, I think putting a deprecation > notice in the docs in v18 is still a good idea. There's no point in hiding > the plan by not documenting it sooner. The more advance notice people get the > bet

Re: Enable data checksums by default

On 24/04/2025 14:26, Peter Eisentraut wrote: On 23.04.25 00:24, Tomas Vondra wrote: The patch that flips the default has been committed. I also started a PG18 open items page and made a note that we follow up on the upgrade experience, as was discussed in this thread. https://wiki.postgresql.o

Re: PG 18 release notes draft committed

On 2025-May-20, Bruce Momjian wrote: > On Tue, May 20, 2025 at 05:15:54PM +0300, Nazir Bilal Yavuz wrote: > > > As of the date of the commit, "Co-authored-by:" is listed as: > > > > > > https://wiki.postgresql.org/wiki/Commit_Message_Guidance > No problem. The "Co-authored-by:" guidance

RE: Re: Re: psql : \dn+ to show default schema privileges

Hi, While testing, I discovered an issue with the \dn+ command's output for schema privileges. When \dn+ is executed: For a schema in its initial state where nspacl is (null), the "Access privileges" field appears empty. After executing REVOKE ALL ON SCHEMA schema_name FROM own

Re: XMLSerialize: version and explicit XML declaration

rebase Best, Jim From 2b684d290cf4d3690e98ca9719af615d137237c8 Mon Sep 17 00:00:00 2001 From: Jim Jones Date: Fri, 23 May 2025 08:59:51 +0200 Subject: [PATCH v3] Add XMLSerialize: version and explicit XML declaration MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Enco

Re: Retiring some encodings?

On 23/05/2025 05:11, Michael Paquier wrote: On Thu, May 22, 2025 at 10:02:16AM -0400, Bruce Momjian wrote: Agreed on notification. A radical idea would be to add a warning for the use of such encodings in PG 18, and then mention their deprecation in the PG 18 release notes so everyone is inform

Re: queryId constant squashing does not support prepared statements

> On Thu, May 22, 2025 at 10:23:31PM GMT, Sami Imseih wrote: > > This does not get squashed: > > Q: select where 2 in (1, 4) and > > 1 in (5, cast(7 as int), 6, (cast(8 as int)), 9, 10, (cast(8 as > > text))::int); > > R: select where $1 in ($2 /*, ... */) and > > $3 in ($4, cast($5 as int), $6, (