On Wed, Jun 11, 2025 at 1:01 PM Florents Tselai
wrote:
>
>
>
> On Wed, Jun 11, 2025 at 12:51 PM Jim Jones
> wrote:
>
>> On 10.06.25 15:37, Florents Tselai wrote:
>> > EDIT: There are test under `src/psql/t` , not sure though how much
>> > coverage the
> On 11 Jun 2025, at 5:23 PM, Nathan Bossart wrote:
>
> On Wed, Jun 11, 2025 at 05:11:54PM +0300, Florents Tselai wrote:
>>> On 11 Jun 2025, at 4:57 PM, Nathan Bossart wrote:
>>> I considered adding another function that would create/attach a DSA in the
>>>
> On 11 Jun 2025, at 4:57 PM, Nathan Bossart wrote:
>
> On Wed, Jun 11, 2025 at 07:15:56PM +0530, Rahila Syed wrote:
>>> How can one dsa_allocate in the same area as the returned dshash_table ?
>>> in other words: shouldn't the state->dsa_handle be returned somehow ?
>>
>> +1. FWIW, Having us
On Wed, Jun 11, 2025 at 12:51 PM Jim Jones
wrote:
> On 10.06.25 15:37, Florents Tselai wrote:
> > EDIT: There are test under `src/psql/t` , not sure though how much
> > coverage they have,
> > but most importantly how it’d look like for this case.
>
> I took a look at
> On 10 Jun 2025, at 8:25 PM, Nathan Bossart wrote:
>
> On Tue, Jun 10, 2025 at 07:47:02PM +0300, Florents Tselai wrote:
>> Love this new API.
>
> Thanks!
>
>> a minor typo here
>> + * current backend. This function gurantees that only one backend
> On 10 Jun 2025, at 7:21 PM, Nathan Bossart wrote:
>
> On Tue, Jun 10, 2025 at 10:38:29AM -0500, Nathan Bossart wrote:
>> On Mon, Jun 09, 2025 at 07:14:28PM -0500, Sami Imseih wrote:
>>> Going back to the original point, DSMRegistryHash and DSMRegistryHash
>>> are built-in, and those names are
> On 10 Jun 2025, at 4:09 PM, Florents Tselai wrote:
>
>
>
>> On 10 Jun 2025, at 3:51 PM, Jim Jones wrote:
>>
>> Hi Florents
>>
>> On 10.06.25 13:36, Florents Tselai wrote:
>>>
>>> On Tue, Jun 10, 2025 at 2:08 AM Jelte Fennema-N
> On 10 Jun 2025, at 3:51 PM, Jim Jones wrote:
>
> Hi Florents
>
> On 10.06.25 13:36, Florents Tselai wrote:
>>
>> On Tue, Jun 10, 2025 at 2:08 AM Jelte Fennema-Nio > <mailto:postg...@jeltef.nl>> wrote:
>>
>>On Mon, 9 Jun 2025
On Tue, Jun 10, 2025 at 2:08 AM Jelte Fennema-Nio
wrote:
> On Mon, 9 Jun 2025 at 17:54, Florents Tselai
> wrote:
> > Here’s a quick attempt that makes %S substitue for a search_path
> > Like
> > \set PROMPT1 'user:%n search_path: %S'
>
> + else
&g
> On 8 Jun 2025, at 2:36 AM, Jelte Fennema-Nio wrote:
>
> On Sat, 7 Jun 2025 at 20:52, Lauri Siltanen wrote:
>> I need to switch search_paths often. It would be tremendously helpful to see
>> the current search_path in the prompt.
>
> That feature should be pretty easy to implement, now that
> On 4 Jun 2025, at 7:19 PM, Nathan Bossart wrote:
>
> On Wed, Jun 04, 2025 at 11:17:42AM +0300, Florents Tselai wrote:
>> Thanks; let's wait a bit to see if there're any objections.
>
> Would you mind combining the patches into just one patch? That's ho
On Tue, Jun 3, 2025 at 11:23 PM Nathan Bossart
wrote:
> This latest patch set looks pretty good to me.
>
Thanks; let's wait a bit to see if there're any objections.
If not, I've taken note of
> created_at might be interesting.
For a separate patch .
mentioned above
> In addition, you may also want to add the C versions of base64rul encode
and decode functions to "src/common/base64.c" as new API calls
Haven't done that, but I could;
Although I think it'd probably be best to do it in a separate patch.
GH PR View https:/
> On 3 Jun 2025, at 10:53 PM, Nathan Bossart wrote:
>
> On Tue, Jun 03, 2025 at 10:39:25PM +0300, Florents Tselai wrote:
>> Thanks for the detailed review Nathan
>
> Thanks for the updated patch!
>
> +if (rsinfo == NULL || !IsA(rsinfo, ReturnSetInfo))
> +
Thanks for the detailed review Nathan
> On 3 Jun 2025, at 4:52 PM, Nathan Bossart wrote:
>
> On Sat, Mar 15, 2025 at 10:41:15AM +0200, Florents Tselai wrote:
>> Here's an updated v3 that fixes some white spaces v2 had-no other changes.
>
> Thanks for the patch.
>
> On 30 May 2025, at 8:27 AM, Noboru Saito wrote:
>
> Thank you Kuroda-san.
>
>> To confirm, generated pdf with current setting is left slide, and it would
>> become like right side, is it correct? I prefer right one.
>
> Sorry for the lack of explanation.
> That's right, the version on the
> On 30 May 2025, at 5:24 PM, Adam Brusselback
> wrote:
>
> Add me to the +1 for having a built-in scheduler. It's useful for plenty of
> things like automated partition creation (as noted), scheduling backups,
> index maintenance, batch processing jobs, etc...
>
> I wrote jpgAgent (compat
> On 27 May 2025, at 4:29 PM, Laurenz Albe wrote:
>
> On Tue, 2025-05-27 at 18:01 +0500, Zaid Shabbir wrote:
>> I’m looking for a complete list of PostgreSQL 17 extensions — both
>> open-source
>> and proprietary. I found a link, but it doesn’t seem to include all
>> available extensions.
>>
> On 25 May 2025, at 1:01 AM, David E. Wheeler wrote:
>
> On May 24, 2025, at 17:55, David E. Wheeler wrote:
>
>> And now I see my patch broke the grammar because I left some of my fiddling
>> in there. Apologies. Here’s an updated patch with the updated keyword map,
>> too.
>
> No, reall
> On 24 May 2025, at 7:08 PM, David E. Wheeler wrote:
>
> On May 23, 2025, at 13:52, Tom Lane wrote:
>
>>> I assume you mean that they’re set at initdb time, so there’s no mutability
>>> concern?
>>
>> Yeah, I think Peter's right and I'm wrong. Obviously this ties into
>> our philosophical
> On 24 May 2025, at 12:24 PM, Álvaro Herrera wrote:
>
> On 2025-May-24, Florents Tselai wrote:
>
>> I aggree with having more READMEs around the src tree.
>> It’s true that a lot of doc content found in VII. Internals is dev-oriented,
>> but imho it should
>
> 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
> 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
-
Cheers,
Flo
tselai.com
<http://tselai.com/?utm_source=email_signature&utm_medium=email&utm_campaign=Email_Signature>
Let's talk ☕ <https://calendly.com/florents-tselai/30min>
v1-0001-Add-pg_proc.dat-comment-mentioning-the-unused_oid.patch
Description: Binary data
> On 22 May 2025, at 5:05 PM, Robert Haas wrote:
>
> On Wed, May 21, 2025 at 2:31 PM Tom Lane wrote:
>> Having said that, what's wrong with inventing some improved function
>> names and never removing the old ones?
>
> I don't particularly like the clutter, but if the consensus is that
> the
> On 19 May 2025, at 6:10 PM, Jacob Champion
> wrote:
>
> On Mon, May 19, 2025 at 6:23 AM Aleksander Alekseev
> wrote:
>> In my experience people who have been contributing for some time use
>> format-patch and provide at least a draft of the commit message,
>> because they know it's more co
> On 13 May 2025, at 11:00 PM, David E. Wheeler wrote:
>
> On May 13, 2025, at 16:24, Florents Tselai wrote:
>
>> As Robert said—and I agree—renaming the existing _tz family would be more
>> trouble than it’s worth, given the need for deprecations, migration pa
> On 13 May 2025, at 2:07 PM, David E. Wheeler wrote:
>
> On May 9, 2025, at 15:50, Robert Haas wrote:
>
>> # We have the kluge of having separate "_tz" functions to support
>> # non-immutable datetime operations, but that way doesn't seem like
>> # it's going to scale well to multiple source
> On 19 Apr 2025, at 7:17 PM, Tom Lane wrote:
>
> Our fine manual claims the answer to $SUBJECT is 3.2.
>
> However, there is room to doubt that our code still actually
> works with 3.2, because the oldest version I can find being
> tested by the buildfarm is topminnow's 3.4.2. The next olde
> On 19 Apr 2025, at 4:18 AM, Yurii Rashkovskii wrote:
>
> Hi,
>
> I propose to introduce `pg_creating_extension()` function that would return
> the OID of the extension being currently created (or `null` if none is).
>
> The core motivation for it is to be able to establish data provenance
ecially, is_pinned will be crucial because
> you cannot unpin the dsm segment twice.
>
> Best regards,
> Sungwoo Chang
>
>
> 2025년 3월 15일 (토) 17:42, Florents Tselai 님이 작성:
>
>>
>>
>>
>>
>> On Fri, Mar 14, 2025 at 11:44 PM Florents Tselai <
>
On Fri, Mar 14, 2025 at 11:44 PM Florents Tselai
wrote:
>
> On Fri, Mar 14, 2025 at 4:16 PM Nathan Bossart
> wrote:
>
>> On Thu, Mar 13, 2025 at 06:54:09PM +0200, Florents Tselai wrote:
>> > I扉e been working with the DSM registry API.
>> > I was wondering if
On Fri, Mar 14, 2025 at 4:16 PM Nathan Bossart
wrote:
> On Thu, Mar 13, 2025 at 06:54:09PM +0200, Florents Tselai wrote:
> > I扉e been working with the DSM registry API.
> > I was wondering if it is possible (it doesn愒 look like it) or if it has
> been discussed:
> > c
On Tue, Mar 11, 2025 at 10:08 AM Florents Tselai
wrote:
>
>
> On Tue, Mar 11, 2025 at 12:51 AM Cary Huang wrote:
>
>> > Oh well - you're probably right.
>> > I guess I was blinded by my convenience.
>> > Adding a 'base64url' option there
I’ve been working with the DSM registry API.
I was wondering if it is possible (it doesn’t look like it) or if it has been
discussed:
can we expose a view like pg_shmem_allocations, but fine-grained for every
named segment (i.e. created by GetNamedDSMSegment )?
Currently, there is a "DSM Registr
On Tue, Mar 11, 2025 at 12:51 AM Cary Huang wrote:
> > Oh well - you're probably right.
> > I guess I was blinded by my convenience.
> > Adding a 'base64url' option there is more appropriate.
>
> I agree with it too. It is neater to add "base64url" as a new option for
> encode() and decode() SQL
On Mon, Mar 10, 2025, 14:32 Daniel Gustafsson wrote:
> > On 10 Mar 2025, at 12:28, Florents Tselai
> wrote:
>
> > Here's a C implementation for this, along with some tests and
> documentation.
> > Tests are copied from cpython's implementation of urls
On Sun, Mar 9, 2025 at 12:28 AM Florents Tselai
wrote:
>
>
> On 7 Mar 2025, at 4:40 PM, Aleksander Alekseev
> wrote:
>
> Hi,
>
> Sometimes support for base64url from RFC 4648 would be useful.
> Does anyone else need a patch like this?
>
>
> While not a freque
> On 7 Mar 2025, at 4:40 PM, Aleksander Alekseev
> wrote:
>
> Hi,
>
>>> Sometimes support for base64url from RFC 4648 would be useful.
>>> Does anyone else need a patch like this?
>>
>> While not a frequent ask, it has been mentioned in the past. I think it
>> would
>> make sense to add so
> On 6 Mar 2025, at 2:10 AM, Ian Lawrence Barwick wrote:
>
> Hi
>
> 2025年3月1日(土) 2:58 Florents Tselai :
>> Please add this to the next Commitfest at
>> https://commitfest.postgresql.org/52/
>>
>>
>> Added ; thanks
>> https://commit
On Thu, Sep 26, 2024 at 1:55 PM Alexander Korotkov
wrote:
> On Thu, Sep 26, 2024 at 12:04 AM Tom Lane wrote:
> > Florents Tselai writes:
> > > This patch is a follow-up and generalization to [0].
> > > It adds the following jsonpath methods: lower, upper, initcap,
> On 20 Feb 2025, at 12:18 AM, Andrew Dunstan wrote:
>
>
>
> On 2025-02-19 We 4:23 PM, Florents Tselai wrote:
>>
>>
>>> On 18 Jan 2025, at 11:51 AM, Florents Tselai
>>> <mailto:florents.tse...@gmail.com> wrote:
>>&g
On 18 Jan 2025, at 11:51 AM, Florents Tselai wrote:On 8 Jan 2025, at 6:45 PM, Andrew Dunstan wrote:On 2024-09-17 Tu 4:53 PM, Florents Tselai wrote:We could, if we're going to do anything at all in this area. Another possibility would be to provide a second optional parameter for j
> On 8 Jan 2025, at 6:45 PM, Andrew Dunstan wrote:
>
>
>
> On 2024-09-17 Tu 4:53 PM, Florents Tselai wrote:
>>
>>> We could, if we're going to do anything at all in this area. Another
>>> possibility would be to provide a second optional pa
> On 17 Oct 2024, at 5:10 PM, Peter Eisentraut wrote:
>
> On 17.10.24 15:56, Tom Lane wrote:
>> Florents Tselai writes:
>>> I think there should be a mention of virtual environments in the plpython
>>> docs.
>> Why? We are not here to teach people
I think there should be a mention of virtual environments in the plpython
docs.
Something like $attached maybe?
v1-0001-Add-tip-on-using-virtual-envs-with-Pl-Python.patch
Description: Binary data
Here's a v2
- note on NULL args/returns
- ref PointerGetDatum
- used your example. Started adding some comments but don't think they're
really necessary. The reader gets the point as-is I think.
v2-0001-Add-some-documentation-on-how-to-call-internal-fu.patch
Description: Binary data
v2-0002-Add
> On 9 Oct 2024, at 2:57 PM, Pavel Stehule wrote:
>
> Hi
>
> I am checking this patch
>
> čt 12. 9. 2024 v 11:42 odesílatel Florents Tselai <mailto:florents.tse...@gmail.com>> napsal:
>> Hi,
>>
>> The documentation on extending using C fu
> On 27 Sep 2024, at 12:45 PM, David E. Wheeler wrote:
>
> On Sep 26, 2024, at 13:59, Florents Tselai wrote:
>
>> Speaking of extensible: the jsonpath standard does mention function
>> extensions [1] ,
>> so it looks like we're covered by the standard,
On Thu, Sep 26, 2024 at 1:55 PM Alexander Korotkov
wrote:
> On Thu, Sep 26, 2024 at 12:04 AM Tom Lane wrote:
> > Florents Tselai writes:
> > > This patch is a follow-up and generalization to [0].
> > > It adds the following jsonpath methods: lower, upper, initcap,
On Sat, Sep 21, 2024 at 9:48 PM Florents Tselai
wrote:
>
>
> > On 21 Sep 2024, at 9:22 PM, Tom Lane wrote:
> >
> > Florents Tselai writes:
> >> Ah, swapped them by mistake on the previous email:
> >> They're both available in the pg_dump a
l of having a prefix like pg_ or
initial-upper letter.
- Still using the default collation like the rest of the jsonpath code.
- documentation N/A yet
- I do realize that the process of adding a new method sketches an
imaginary.
CREATE JSONPATH FUNCTION. This has been on the back of my mind for some
> On 21 Sep 2024, at 9:22 PM, Tom Lane wrote:
>
> Florents Tselai writes:
>> Ah, swapped them by mistake on the previous email:
>> They're both available in the pg_dump and note on -n missing in pg_restore.
>> The question remains though:
>> Shouldn’t
On Sat, Sep 21, 2024 at 8:34 PM Florents Tselai
wrote:
> I’m in the process of trying to restore some PG15/16 backups in PG17.
>
> While playing with different -t and -n combinations I was browsing through
> the docs.
>
> In *pg_restore* there are two notes about both -t / -n
I’m in the process of trying to restore some PG15/16 backups in PG17.
While playing with different -t and -n combinations I was browsing through the
docs.
In pg_restore there are two notes about both -t / -n
> When -n / -t is specified, pg_dump makes no attempt to ...
In pg_dump though there’
On 18 Sep 2024, at 3:47 PM, Andrew Dunstan wrote:
On 2024-09-18 We 4:23 AM, Peter Eisentraut wrote:
On 17.09.24 21:16, David E. Wheeler wrote:
On Sep 17, 2024, at 15:03, Florents Tselai
wrote:
Fallback scenario: make this an extension, but in a first pass I didn’t
find any convenient hooks
On Wed, Sep 18, 2024 at 1:09 PM Pavel Stehule
wrote:
> Hi
>
> st 18. 9. 2024 v 9:04 odesílatel Florents Tselai <
> florents.tse...@gmail.com> napsal:
>
>> Correct me if I'm wrong,
>> but for an extension that defines composite types,
>> there's c
> On 18 Sep 2024, at 11:23 AM, Peter Eisentraut wrote:
>
> On 17.09.24 21:16, David E. Wheeler wrote:
>> On Sep 17, 2024, at 15:03, Florents Tselai wrote:
>>> Fallback scenario: make this an extension, but in a first pass I didn’t
>>> find any convenient hoo
Correct me if I'm wrong,
but for an extension that defines composite types,
there's currently no easy way to get a TupleDesc, even for its own types.
Something like
TupleDesc get_extension_type_tupledesc(const char *extname, const char
*typname)
Here's a routine I've stolen borrowed from pramsey'
On Tue, Sep 17, 2024 at 5:11 PM Andrew Dunstan wrote:
>
> On 2024-09-17 Tu 5:26 AM, Florents Tselai wrote:
>
> Currently:
>
>
> jsonb_strip_nulls ( jsonb ) → jsonb
>
> Deletes all object fields that have null values from the given JSON value,
> recursively. Null val
> On 17 Sep 2024, at 9:40 PM, David E. Wheeler wrote:
>
> On Sep 16, 2024, at 18:39, Florents Tselai wrote:
>
>> Here’s an updated version of this patch.
>
> Oh, nice function.
>
> But a broader question for hackers: Is replace() specified in the SQL/JS
Currently:
jsonb_strip_nulls ( jsonb ) → jsonb
Deletes all object fields that have null values from the given JSON value,
recursively. Null values that are not object fields are untouched.
> Null values that are not object fields are untouched.
Can we revisit this and make it work with arrays
, jpiString)use jspGetRightArg and jspGetLeftArg.left and right can be confusing if more complex methods are added in the future.i.e. jsonpath methods with nargs>=3 .I was wondering if we’d like something like JSP_GETARG(n)GitHub PR in case you prefer it’s UI https://github.com/Florents-Tse
Hi,When working with jsonb/jsonpath, I’ve always wanted more fluent string operations for data cleaning.Ideally, chaining text processing methods together.Here’s a draft patch that adds a string replace method.It works like thisselect jsonb_path_query('"hello world"', '$.replace("hello","bye")'); j
> On 13 Sep 2024, at 11:07 PM, Andrew Kane wrote:
>
> Hi,
>
> With Postgres 17 RC1 on Windows, `float_to_shortest_decimal_buf` and
> `float_to_shortest_decimal_bufn` are not longer exported. This causes
> `unresolved external symbol` linking errors for extensions that rely on these
> funct
/Florents-Tselai/postgres/pull/1/commits/1651b7bb68e0f9c2b61e1462367295d846d253ec
0001-Add-some-documentation-on-how-to-call-internal-funct.patch
Description: Binary data
./configure —help
It will show that you can build —without-icu ,
you can also specify a path to pkg-config via PKG_CONFIG=/path/to/pkg-config
side note: I’ve had better experience building with brew on macos, rather than
macports.
> On 4 Jul 2024, at 9:02 PM, Said Assemlal wrote:
>
> Hi,
>
In the ddl.sgml, I’d swap the first two paragraphs.
I find the first one a bit confusing as-is. As far as I can tell, it’s an
implementation detail.
The first paragraph should answer, “I have some data modeled as a graph G=(V,
E). Can Postgres help me?”.
Then, introducing property graphs makes m
Has anyone put this in a git repo / extension package or similar ?
I’d like to try it out outside the core pg tree.
> On 1 Jul 2023, at 12:04 PM, Joel Jacobson wrote:
>
> On Fri, Jun 30, 2023, at 06:50, jian he wrote:
>> more like a C questions
>> in this context does
>> #define HASHSET_GET_V
> On 7 Jun 2023, at 12:13 AM, Peter Eisentraut wrote:
>
> On 03.06.23 19:47, Florents Tselai wrote:
>> There’s another previous relevant patch [0] but was never merged. I’ve
>> included these stop words and added some more (info in README.md).
>> For my personal pr
I posted earlier in pgsql-general, that I realised there’s no greek.stop under
$(pg_config —sharedir)/tsearch_data
And indeed looks like stop words are maintained with to_tsvector(‘greek’, ..).
I wrote an extension https://github.com/Florents-Tselai/pg_fts_greek that adds
another ‘greek_ext
71 matches
Mail list logo
