Pavel Stehule writes:
> Own implementation of SQL/XML generating functions like XMLFOREST or
> XMLELEMENT should not be too
> difficult. Significantly more difficult problem is parsing of XML (more
> with namespaces), although some basic
> support for XMLTABLE should not be too hard too.
I don't
čt 19. 6. 2025 v 22:09 odesílatel Bruce Momjian napsal:
> On Thu, Jun 19, 2025 at 09:24:32PM +0200, Jim Jones wrote:
> > On 19.06.25 03:41, Bruce Momjian wrote:
> > > This blog post explains the serious problems the single libxml2 author
> > > is having in maintaining the library:
> > >
> > >
> h
On Thu, Jun 19, 2025 at 5:51 PM Aleksander Alekseev
wrote:
>
> Hi,
>
> Michael (cc:'ed) pointed out [1] that pg_bsd_indent could do a
> slightly better job when it comes to formatting multiline comments. I
> prepared a patch that fixes this.
>
> How to test it:
>
> ```
> ninja -C build
> cp build/
On Wed, Jun 18, 2025 at 02:48:16PM -0400, shihao zhong wrote:
>>> That leads me to think (1) might be the better option, although I'm not too
>>> wild about the subtlety of the fix.
>
> Thanks for your feedback. New patch is attached. I also updated the
> signature of do_analyze_rel for the same r
While investigating problems caused by vacuum_rel() scribbling on its
VacuumParams argument [0], I noticed some other interesting bugs with the
toast.* reloption code. Note that the documentation for the reloptions has
the following line:
If a table parameter value is set and the equivale
On Thu, Jun 19, 2025 at 09:24:32PM +0200, Jim Jones wrote:
> On 19.06.25 03:41, Bruce Momjian wrote:
> > This blog post explains the serious problems the single libxml2 author
> > is having in maintaining the library:
> >
> >
> > https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulne
On 19.06.25 03:41, Bruce Momjian wrote:
> This blog post explains the serious problems the single libxml2 author
> is having in maintaining the library:
>
>
> https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-reports
>
> There are few learnings from this:
>
> * libx
On Mon, 19 May 2025 at 09:38, Nathan Bossart wrote:
> Could you retry your tests on v18devel? It might also be useful to
repeat the tests on a variety of hardware to ensure
> it's a win across the board.
Hi Nathan,
Thanks for your clarification. As you requested, I have performed more
tests on
On 6/19/25 08:43, Jeff Davis wrote:
Leaving it in the entry for PARTITION BY seems out of place; shouldn't
it be moved to the entry for EXCLUDE? I also merged your wording with
some similar wording from the entry about UNIQUE. Attached.
I agree this new location makes more sense. The wording lo
On Thu, 19 Jun 2025 at 18:39, David E. Wheeler wrote:
>
> On Jun 19, 2025, at 12:59, Thom Brown wrote:
>
> > No. But given the options, I would personally choose nondeterministic
> > collations now that they are available. I just wish they were more
> > user-friendly as I suspect the majority o
On Wed, Jun 18, 2025 at 2:39 PM Andrey Borodin wrote:
>
>
>
> > On 18 Jun 2025, at 11:33, Arseniy Mukhin
> > wrote:
> >
> > Interesting, I used btree check as reference when started
> > writing brin check, and in btree check there 53
> > ERRCODE_INDEX_CORRUPTED ereports and only 1 ERRCODE_DATA_C
On Thu, 2025-06-19 at 14:14 +1000, Peter Smith wrote:
> Here are the v8 patches. The main changes are as follows:
>
> v8-0001 VCI - changes to postgres core
> - same
>
> v8-0002 VCI module - main
> - extracted "compression" related code from this main patch
> - applied Timur's top-up patch [1] re
On Tue, 2025-06-03 at 00:51 +0300, Alexander Borisov wrote:
> As promised, I continue to improve/speed up Unicode in Postgres.
> Last time, we improved the lower(), upper(), and casefold()
> functions. [1]
> Now it's time for Unicode Normalization Forms, specifically
> the normalize() function.
Di
On Jun 19, 2025, at 12:59, Thom Brown wrote:
> No. But given the options, I would personally choose nondeterministic
> collations now that they are available. I just wish they were more
> user-friendly as I suspect the majority of people either won't know about
> them, or won't know how to use
On Thu, 19 Jun 2025, 17:33 Jeff Davis, wrote:
> On Thu, 2025-06-19 at 16:36 +0100, Thom Brown wrote:
> > Ease of use, perhaps. It seems easier to use:
> >
> > column_name cftext
> >
> > rather than:
> >
> > CREATE COLLATION case_insensitive_collation (
> > PROVIDER = icu,
> > LOCALE = 'un
On Thu, 2025-06-19 at 18:21 +0200, Vik Fearing wrote:
> >
> > The SQL standard also says in a few other places that normalization
> > should be applied, and we do none of those, so this is probably not
> > a
> > reason to change CASEFOLD at this point.
> >
>
> Works for me.
Sounds good. We can
On Thu, Jun 19, 2025 at 12:33 PM Jeff Davis wrote:
>
> On Thu, 2025-06-19 at 16:36 +0100, Thom Brown wrote:
> > Ease of use, perhaps. It seems easier to use:
> >
> > column_name cftext
> >
> > rather than:
> >
> > CREATE COLLATION case_insensitive_collation (
> > PROVIDER = icu,
> > LOCALE
On Thu, 2025-06-19 at 16:36 +0100, Thom Brown wrote:
> Ease of use, perhaps. It seems easier to use:
>
> column_name cftext
>
> rather than:
>
> CREATE COLLATION case_insensitive_collation (
> PROVIDER = icu,
> LOCALE = 'und-u-ks-level2',
> DETERMINISTIC = FALSE
> );
We could auto-c
On 19/06/2025 16:47, Peter Eisentraut wrote:
On 17.06.25 17:37, Vik Fearing wrote:
For (which includes LOWER() and UPPER()), the text says in
Section 6.35 GR 7.e:
If the character set of is UTF8, UTF16, or UTF32,
then FR is replaced by
Case:
i) If the S IS NORMALIZED eval
On Thu, Jun 19, 2025 at 11:37 AM Thom Brown wrote:
> On Thu, 19 Jun 2025 at 15:51, Peter Eisentraut wrote:
> > On 19.06.25 06:03, Thom Brown wrote:
> > > Late to the party, but is there an argument for porting this to the
> > > citext type? Or supplementing the extension with an additional type
>
On Wed, 2025-06-18 at 11:25 -0700, Paul Jungwirth wrote:
> Hi Hackers,
>
> In pg17 we added support for cross-partition EXCLUDE constraints, as
> long as they included all
> partition key columns and compared them with equality (see
> 8c852ba9a4). I updated the docs for
> exclusion constraints,
On Thu, 19 Jun 2025 at 15:51, Peter Eisentraut wrote:
>
> On 19.06.25 06:03, Thom Brown wrote:
> > Late to the party, but is there an argument for porting this to the
> > citext type? Or supplementing the extension with an additional type
> > ("cftext"? *shrug*). It currently uses lower(), so our
"David G. Johnston" writes:
> At this point why does it matter what the docs says?
Yeah, I cannot get excited about changing this. The current protocol
spec accurately documents what we do. It is not incumbent on us to
document what non-Postgres implementations of this protocol could
hypothetic
čt 19. 6. 2025 v 11:00 odesílatel Álvaro Herrera
napsal:
> On 2025-Jun-18, Bruce Momjian wrote:
>
> > This blog post explains the serious problems the single libxml2 author
> > is having in maintaining the library:
> >
> >
> https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-
Peter Eisentraut writes:
> On 19.06.25 08:40, Nazir Bilal Yavuz wrote:
>> Thanks for the patches! I didn't check them yet but I encountered some
>> errors while using meson 0.57.0 and 0.57.1 but 0.56.2, 0.57.2 and
>> 0.58.0 worked successfully. These errors seem to be related to these
>> specific
On Thu, Jun 19, 2025 at 05:05:25PM +0200, Daniel Gustafsson wrote:
> I also dug out an archeologically old MacBook Pro running macOS High Sierra
> 10.13.6 with an i5 using Apple LLVM version 10.0.0 (clang-1000.10.44.4), and
> it
> too fails to reproduce any issue.
It's not going to be reproducibl
> On 19 Jun 2025, at 16:36, Andres Freund wrote:
> So for some reason this apparently can only be reproduced on older macos - we
> know it's not the older compiler, because I couldn't reproduce it on the same
> compile version as alexander, on an m1 that was running sequoia. That's really
> reall
Hi,
Michael (cc:'ed) pointed out [1] that pg_bsd_indent could do a
slightly better job when it comes to formatting multiline comments. I
prepared a patch that fixes this.
How to test it:
```
ninja -C build
cp build/src/tools/pg_bsd_indent/pg_bsd_indent ~/bin/pg_bsd_indent
cp src/tools/pgindent/p
On 19.06.25 06:03, Thom Brown wrote:
Late to the party, but is there an argument for porting this to the
citext type? Or supplementing the extension with an additional type
("cftext"? *shrug*). It currently uses lower(), so our current
recommendation for dealing with all unicode characters is t
On 17.06.25 17:37, Vik Fearing wrote:
For (which includes LOWER() and UPPER()), the text says in
Section 6.35 GR 7.e:
If the character set of is UTF8, UTF16, or UTF32,
then FR is replaced by
Case:
i) If the S IS NORMALIZED evaluates to True,
then NORMALIZE (FR)
ii
On Thursday, June 19, 2025, Tatsuo Ishii wrote:
>
> > FWIW my reading of the protocol docs is that BackendKeyData is
> > optional.
>
> If majority of developers think so, do we want to update the protocol
> docs? For me the docs is not clear enough.
>
At this point why does it matter what the do
Hi,
On 2025-06-19 17:02:18 +0300, Konstantin Knizhnik wrote:
> On 18/06/2025 7:08 pm, Andres Freund wrote:
> > Hi,
> >
> > On 2025-06-18 10:32:08 +0300, Konstantin Knizhnik wrote:
> > > On 17/06/2025 6:08 pm, Andres Freund wrote:
> > > > I don't think it can - this must be an independent bug from
> On 19 Jun 2025, at 16:02, Konstantin Knizhnik wrote:
> By the way - still not been able to reproduce assertion failure at most
> recent MacPro (Apple M4 Pro) with Sequoia 15.5.
I tried to reproduce this on an older quad core i7 MacBook Pro running Sonoma
14.7.5 using Apple clang version 15.0.
On 18/06/2025 7:08 pm, Andres Freund wrote:
Hi,
On 2025-06-18 10:32:08 +0300, Konstantin Knizhnik wrote:
On 17/06/2025 6:08 pm, Andres Freund wrote:
I don't think it can - this must be an independent bug from the one that Tom
and I were encountering.
I see... It's a pity.
Indeed.
Konstant
Hi,
Hi,
On 2025-06-18 10:58:22 +0200, Peter Eisentraut wrote:
> On 17.06.25 19:36, Peter Eisentraut wrote:
> > meson.build currently says
> >
> > # We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
> > # RHEL 7 has 0.55. < 0.54 would require replacing some uses of the fs
> >
On 18.06.25 22:57, Robert Treat wrote:
I also wondered why you differentiated SQL script file vs archive in
the change here:
- of a cluster into an archive. The archive contains
+ of a cluster into an SQL script file or an archive. The output contains
but then did not differentiate them h
> Or disconnect.
You cannot disconnect without canceling the query at least using psql.
You can kill psql to disconnect but it's possible that the backend
keeps on running the query.
> Or pg_cancel_backend().
In order to issue pg_cancel_backend() the user needs to know the
backend pid which was
On Thu, 19 Jun 2025 at 13:51, Tatsuo Ishii wrote:
> > FWIW my reading of the protocol docs is that BackendKeyData is
> > optional.
>
> If majority of developers think so, do we want to update the protocol
> docs? For me the docs is not clear enough.
I think the docs currently definitely suggests
On 2025/06/19 14:42, jian he wrote:
On Wed, Jun 18, 2025 at 10:21 AM Fujii Masao
wrote:
I ran into another issue related to comments on NOT NULL constraints.
When using CREATE TABLE ... (LIKE ... INCLUDING ALL), the NOT NULL constraints
are copied, but their comments are not. For example:
Dear Amit, Alexander,
> > Regarding assertion failure, I've found that assert in
> > PhysicalConfirmReceivedLocation() conflicts with restart_lsn
> > previously set by ReplicationSlotReserveWal(). As I can see,
> > ReplicationSlotReserveWal() just picks fresh XLogCtl->RedoRecPtr lsn.
> > So, it d
>
> Here is the V38 patch set which includes the following changes:
>
Thank You for the patches. Few comments:
1)
+
+Note that commit timestamps and origin data retained by enabling the
+retain_conflict_info
+option will not be preserved during the upgrade. As a
+result, the up
Hi Michael,
> /* text_name()
> * Converts a text type to a Name type.
> */
>
> Not related to this patch, sorry for the regression, just noticed
> a nit while looking at the diffs of what you have here.. This one, as
> well as name_text(), uses a comment block that is inconsistent with
> the fo
On Wed, Jun 18, 2025 at 10:17 PM Alexander Korotkov
wrote:
>
> On Wed, Jun 18, 2025 at 6:50 PM Vitaly Davydov
> wrote:
> > > I think, it is a good idea. Once we do not use the generated data, it is
> > > ok
> > > just to generate WAL segments using the proposed function. I've tested
> > > this
On 2025-Jun-18, Bruce Momjian wrote:
> This blog post explains the serious problems the single libxml2 author
> is having in maintaining the library:
>
>
> https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-reports
>
> There are few learnings from this:
>
> * libxml
On 19/06/2025 13:03, Tatsuo Ishii wrote:
I think that's fine, if the server does not want to support query
cancellation. The current protocol description certainly does not
support the idea that it is a hard error *not* to send BackendKeyData.
Isn't it scary if the server does not allow a quer
> I think that's fine, if the server does not want to support query
> cancellation. The current protocol description certainly does not
> support the idea that it is a hard error *not* to send BackendKeyData.
Isn't it scary if the server does not allow a query cancel? For
example, if the server
Hi,
On Wed, Jun 18, 2025 at 03:22:59PM +0530, shveta malik wrote:
> On Wed, Jun 18, 2025 at 2:39 PM Bertrand Drouvot
> wrote:
> >
> > IIUC the idea is to "just" increase WAL level to 'logical' so that one
> > could then
> > be allowed to make use of logical decoding from the standby. The primary
On Tue, Jun 17, 2025 at 4:26 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Mon, Jun 16, 2025 at 7:37 PM Amit Kapila wrote:
> >
> >
> > 3. Isn't the new check for logical slots in
> > check_new_cluster_subscription_configuration() somewhat redundant with
> > the previous check done in check_new_cluster_log
On Wed, Jun 18, 2025 at 10:56 AM Amit Kapila wrote:
>
> On Wed, Jun 18, 2025 at 8:52 AM shveta malik wrote:
> >
> > On Tue, Jun 17, 2025 at 12:01 PM Amit Kapila
> > wrote:
> > >
> > > This whole paragraph sounds like a duplicate of its previous section,
> > > and the line alignment in the first
Hi,
Thanks for your valuable feedback on the patch.
Will check on the cases mentioned by you and do the needful.
Best Regards
Shubhankar K.
Member Technical Staff
Zoho Corporation
On Sat, 14 Jun 2025 09:03:25 +0530 Andy Fan wrote
---
Shubhankar Anand Kulkarni < mailto:shubhankar
On Wed, Jun 18, 2025 at 09:15:07AM +0200, Jelte Fennema-Nio wrote:
> On Wed, 18 Jun 2025 at 08:23, Anthonin Bonnefoy
> wrote:
>> Since \bind_named is also new, we can also rename it to make it
>> consistent with close meta-command. So what about renaming \bind_named
>> to \bindprepared and \close
On 17.06.25 03:10, Tatsuo Ishii wrote:
My question is, BackendKeyData is mandatory or not. Currently
Pgpool-II raises a fatal error if BackendKeyData is not sent before
ReadyForQuery arrives. This is because without the message, frontend
cannot send a CancelRequest message later on, as there's no
On 19.06.25 08:40, Nazir Bilal Yavuz wrote:
Thanks for the patches! I didn't check them yet but I encountered some
errors while using meson 0.57.0 and 0.57.1 but 0.56.2, 0.57.2 and
0.58.0 worked successfully. These errors seem to be related to these
specific minor versions,
I think it's okay to
53 matches
Mail list logo
