jian he writes:
> On Fri, Jul 26, 2024 at 10:40 PM Tom Lane wrote:
>> Hmm, yeah, you're right. I didn't want to write two separate
>> synopses there, but maybe there's no choice.
> Now the output is
> It has the syntax regexp_replace(string, pattern, replacement [, flags
> ]) and regexp_replace
On Fri, Jul 26, 2024 at 10:40 PM Tom Lane wrote:
>
> jian he writes:
> > On Fri, Jul 26, 2024 at 10:17 PM Tom Lane wrote:
> >> AFAICS, that one is correct, so I left it alone. (I didn't try to
> >> merge the table's two entries into one like that, though.)
>
> > regexp_replace(string, pattern,
jian he writes:
> On Fri, Jul 26, 2024 at 10:17 PM Tom Lane wrote:
>> AFAICS, that one is correct, so I left it alone. (I didn't try to
>> merge the table's two entries into one like that, though.)
> regexp_replace(string, pattern, replacement [, start [, N ]] [, flags ]).
> can represent
> r
On Fri, Jul 26, 2024 at 10:17 PM Tom Lane wrote:
>
> > <<
> > It has the syntax regexp_replace(string, pattern, replacement [, start
> > [, N ]] [, flags ]). (Notice that N cannot be specified unless start
> > is, but flags can be given in any case.)
> > <<
> > doc, the above part still needs chan
jian he writes:
> On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote:
>> but it is not: we have no function matching that signature. I'm not
>> in a hurry to add one, either, for fear of ambiguity against the other
>> regexp_replace signature. I think this needs to be broken into two
>> syntax diag
On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote:
>
> The small issue is that table 9.10 offers this syntax diagram
> for regexp_replace:
>
> regexp_replace ( string text, pattern text, replacement text [, start integer
> ] [, flags text ] ) → text
>
> This implies that it's valid to write
>
>
I wrote:
> I haven't heard any further bikeshedding on the argument names,
> so I'll move forward with committing this soon.
Pushed, after a little further fooling with the documentation.
regards, tom lane
On 15.07.24 16:52, Chapman Flack wrote:
On 07/15/24 10:46, Chapman Flack wrote:
Ah, I may have mistaken which functions the patch meant to apply to.
...
Any choice to use similar argument names in the regexp_* functions would
be a matter of consistency with the analogous ISO functions, not anyth
jian he writes:
> On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote:
>> The larger issue is that contrib/citext offers versions of some of
>> these functions that are meant to be drop-in replacements using
>> citext input. Hence, we need to add the same parameter names to
>> those functions, or the
On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote:
>
> jian he writes:
> > [ v5-0001-add-regex-functions-argument-names-to-pg_proc.patch ]
>
> I'm not sure whether we've bikeshedded this to death yet, but
> personally I'm content with the naming choices here (which basically
> are those already show
jian he writes:
> [ v5-0001-add-regex-functions-argument-names-to-pg_proc.patch ]
I'm not sure whether we've bikeshedded this to death yet, but
personally I'm content with the naming choices here (which basically
are those already shown in table 9.10). However, while looking
at the patch I notic
On 07/15/24 10:46, Chapman Flack wrote:
> Ah, I may have mistaken which functions the patch meant to apply to.
> ...
> Any choice to use similar argument names in the regexp_* functions would
> be a matter of consistency with the analogous ISO functions, not anything
> mandated.
Or, looking back,
On 07/15/24 08:02, jian he wrote:
> also address Chapman Flack point:
> correct me if i am wrong, but i don't think the ISO standard mandates
> function argument names.
> So we can choose the best function argument name for our purpose?
Ah, I may have mistaken which functions the patch meant to ap
On Thu, May 16, 2024 at 3:10 AM Tom Lane wrote:
>
> Robert Haas writes:
> > On Thu, Apr 4, 2024 at 9:55 AM jian he wrote:
> >> changing "N" to lower-case would be misleading for regexp_replace?
> >> so I choose "count".
>
> > I don't see why that would be confusing for regexp_replace
> > specifi
On Wed, May 15, 2024 at 4:25 PM David G. Johnston
wrote:
> Maybe just "match" instead of "replace_match".
Well, this is just turning into a bikeshedding exercise at this point.
We can generate names for this parameter all day long, but a bunch of
names none of which gets more than one vote is not
On 05/15/24 15:31, Robert Haas wrote:
> On Wed, May 15, 2024 at 3:23 PM Chapman Flack wrote:
>> What would be wrong with [occurrence], for consistency's sake?
>
> It was proposed and rejected upthread, but that's not to say that I
> necessarily endorse the reasons given.
Apologies for not having
On Wed, May 15, 2024 at 1:19 PM Robert Haas wrote:
>
> So my point was: to me, N is more self-documenting than replace_at,
> and less self-documenting than count or occurrence.
>
> If your mileage varies on that point, so be it!
>
>
Maybe just "match" instead of "replace_match".
Reading this it
On Wed, May 15, 2024 at 4:13 PM David G. Johnston
wrote:
>
> You just broke my brain when you say that you read:
>
> By default, only the first match of the pattern is replaced. If replace_at
> is specified and greater than zero, then the first "replace_at - 1" matches
> are skipped before maki
On Wed, May 15, 2024 at 12:07 PM Robert Haas wrote:
> On Wed, May 15, 2024 at 3:01 PM David G. Johnston
> wrote:
> > I think this confusion goes to show that replacing N with count doesn't
> work.
> >
> > "replace_at" comes to mind as a better name.
> I'd expect replace_at to be a
> character po
On Wed, May 15, 2024 at 12:52 PM Robert Haas wrote:
> On Wed, May 15, 2024 at 3:25 PM David G. Johnston
> wrote:
> > The function replaces matches, not random characters. And if you are
> reading the documentation I find it implausible that the wording I
> suggested would cause one to think in
On Wed, May 15, 2024 at 3:25 PM David G. Johnston
wrote:
> The function replaces matches, not random characters. And if you are reading
> the documentation I find it implausible that the wording I suggested would
> cause one to think in terms of characters instead of matches.
I mean I just tol
On Wed, May 15, 2024 at 3:23 PM Chapman Flack wrote:
> What would be wrong with that, for consistency's sake?
It was proposed and rejected upthread, but that's not to say that I
necessarily endorse the reasons given.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, May 15, 2024 at 12:07 PM Robert Haas wrote:
> On Wed, May 15, 2024 at 3:01 PM David G. Johnston
> wrote:
> > I think this confusion goes to show that replacing N with count doesn't
> work.
> >
> > "replace_at" comes to mind as a better name.
>
> I do not agree with that at all. It shows
On 05/15/24 15:07, Robert Haas wrote:
> is. I believe that if I were reading the documentation, count would be
> clearer to me than N, N would probably still be clear enough, and
> replace_at wouldn't be clear at all. I'd expect replace_at to be a
> character position or something, not an occurrenc
Robert Haas writes:
> On Thu, Apr 4, 2024 at 9:55 AM jian he wrote:
>> changing "N" to lower-case would be misleading for regexp_replace?
>> so I choose "count".
> I don't see why that would be confusing for regexp_replace
> specifically, but I think N => count is a reasonable change to make.
>
On Wed, May 15, 2024 at 3:01 PM David G. Johnston
wrote:
> I think this confusion goes to show that replacing N with count doesn't work.
>
> "replace_at" comes to mind as a better name.
I do not agree with that at all. It shows that a literal
search-and-replace changing N to count does not work,
On Wed, May 15, 2024 at 11:46 AM Robert Haas wrote:
> On Thu, Apr 4, 2024 at 9:55 AM jian he
> wrote:
> > in the regexp_replace explanation section.
> > changing "N" to lower-case would be misleading for regexp_replace?
> > so I choose "count".
>
> I don't see why that would be confusing for reg
On Wed, May 15, 2024 at 2:46 PM Robert Haas wrote:
> Examples in the regression tests aren't meant as tests, not examples
> for users to copy. If we want examples, those belong in the
> documentation. However, I see that regexp_replace already has some
> examples at
> https://www.postgresql.org/d
On Thu, Apr 4, 2024 at 9:55 AM jian he wrote:
> in the regexp_replace explanation section.
> changing "N" to lower-case would be misleading for regexp_replace?
> so I choose "count".
I don't see why that would be confusing for regexp_replace
specifically, but I think N => count is a reasonable ch
On Wed, Apr 3, 2024 at 4:45 AM Tom Lane wrote:
>
> jian he writes:
> > On Thu, Jan 18, 2024 at 4:17 PM Peter Eisentraut
> > wrote:
> >> Reading back through the discussion, I wasn't quite able to interpret
> >> the resolution regarding Oracle compatibility. From the patch, it looks
> >> like y
jian he writes:
> On Thu, Jan 18, 2024 at 4:17 PM Peter Eisentraut wrote:
>> Reading back through the discussion, I wasn't quite able to interpret
>> the resolution regarding Oracle compatibility. From the patch, it looks
>> like you chose not to adopt the parameter names from Oracle. Was that
On Sat, Jan 20, 2024 at 10:55 AM jian he wrote:
>
>
> another regex* function argument changes: from "N" to "occurences", example:
> + If occurrence is specified
> + then the occurrence'th match of the pattern
> + is located,
>
> but [2] says
> Speaking of the "occurrence'th
> occurre
On Thu, Jan 18, 2024 at 4:17 PM Peter Eisentraut wrote:
>
> On 10.01.24 15:18, jian he wrote:
> > I put the changes into the new patch.
>
> Reading back through the discussion, I wasn't quite able to interpret
> the resolution regarding Oracle compatibility. From the patch, it looks
> like you ch
On 10.01.24 15:18, jian he wrote:
I put the changes into the new patch.
Reading back through the discussion, I wasn't quite able to interpret
the resolution regarding Oracle compatibility. From the patch, it looks
like you chose not to adopt the parameter names from Oracle. Was that
your i
On Wed Jan 10, 2024 at 9:18 AM EST, jian he wrote:
> On Tue, Jan 9, 2024 at 8:52 AM Dian Fay wrote:
> >
> > On Mon Jan 8, 2024 at 9:26 AM EST, jian he wrote:
> > > On Mon, Jan 8, 2024 at 8:44 AM Dian Fay wrote:
> > > > The `regexp_replace` summary in table 9.10 is mismatched and still
> > > > spe
ate
> > that the
> > substring matching the entire pattern should be inserted. Write
> > \\ if you need to put a literal backslash in
> > the replacement
> > text.
>
> That change makes sense to me! I'll see about the section refactoring
On Mon Jan 8, 2024 at 9:26 AM EST, jian he wrote:
> On Mon, Jan 8, 2024 at 8:44 AM Dian Fay wrote:
> > The `regexp_replace` summary in table 9.10 is mismatched and still
> > specifies the first parameter name as `string` instead of `source`.
> > Since all the other functions use `string`, should `
On Mon, Jan 8, 2024 at 8:44 AM Dian Fay wrote:
>
> On Thu Jan 4, 2024 at 2:03 AM EST, jian he wrote:
> > On Thu, Jan 4, 2024 at 7:26 AM Jim Nasby wrote:
> > >
> > > On 1/3/24 5:05 PM, Dian Fay wrote:
> > >
> > > Another possibility is `index`, which is relatively short and not a
> > > reserved ke
On Thu Jan 4, 2024 at 2:03 AM EST, jian he wrote:
> On Thu, Jan 4, 2024 at 7:26 AM Jim Nasby wrote:
> >
> > On 1/3/24 5:05 PM, Dian Fay wrote:
> >
> > Another possibility is `index`, which is relatively short and not a
> > reserved keyword ^1. `position` is not as precise but would avoid the
> > c
e.
to change from `N` to `occurrence`, we also need to change the doc,
that is why this patch is more larger.
[0]:
https://www.google.com/search?q=regex+nth+match&oq=regex+nth+match&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQRRg8MgYIAhBFGDzSAQc2MThqMGo5qAIAsAIA&sourceid=chrome&ie=UTF-8
From cb720fd696df3a34032ec
On 1/3/24 5:05 PM, Dian Fay wrote:
Another possibility is `index`, which is relatively short and not a
reserved keyword ^1. `position` is not as precise but would avoid the
conceptual overloading of ordinary indices.
I'm not a fan o
> > Another possibility is `index`, which is relatively short and not a
> > reserved keyword ^1. `position` is not as precise but would avoid the
> > conceptual overloading of ordinary indices.
>
> I'm not a fan of "index" since that leaves the question of
> whether it's 0 or 1 based. "Position" is
On 1/1/24 12:05 PM, Dian Fay wrote:
I agree that the parameter name `n` is not ideal. For example, in
`regexp_replace` it's easy to misinterpret it as "make up to n
replacements". This has not been a problem when `n` only lives in the
documentation which explains exactly
On 28.12.23 04:28, jian he wrote:
I looked around the oracle implementation in [1], and the oracle regex
related function argumentation name in [2]
I use the doc [3] syntax explanation and add the related function names.
Current, regex.* function syntax seems fine. but only parameter `N`
seems a
On Wed Dec 27, 2023 at 10:28 PM EST, jian he wrote:
> On Thu, Dec 28, 2023 at 6:25 AM Peter Eisentraut wrote:
> >
> > On 27.12.23 17:53, jian he wrote:
> > > similar to [1], add function argument names to the following functions:
> > > regexp_like, regexp_match,regexp_matches,regexp_replace,
> > >
On Thu, Dec 28, 2023 at 6:25 AM Peter Eisentraut wrote:
>
> On 27.12.23 17:53, jian he wrote:
> > similar to [1], add function argument names to the following functions:
> > regexp_like, regexp_match,regexp_matches,regexp_replace,
> > regexp_substr,regexp_split_to_array,regexp_split_to_table,regex
On 27.12.23 17:53, jian he wrote:
similar to [1], add function argument names to the following functions:
regexp_like, regexp_match,regexp_matches,regexp_replace,
regexp_substr,regexp_split_to_array,regexp_split_to_table,regexp_count
Note that these functions are a quasi-standard that is shared
,
which doesn't look good, so I gave up.
[1]
https://www.postgresql.org/message-id/flat/877cw3jl8y@wibble.ilmari.org
[2]
https://www.postgresql.org/docs/current/sql-syntax-calling-funcs.html#SQL-SYNTAX-CALLING-FUNCS
[3] https://www.postgresql.org/docs/current/functions-matching.html
From f86
48 matches
Mail list logo
