2022年10月3日(月) 1:55 Andres Freund :
>
> Hi,
>
> The patch for this CF entry doesn't apply currently, and it looks like that's
> been the case for quite a while...
As that's remained the case and the last update from the author was in
May, we'll
close this as "returned with feedback". A new entry
Hi,
The patch for this CF entry doesn't apply currently, and it looks like that's
been the case for quite a while...
Greetings,
Andres Freund
On Tue, May 3, 2022 at 8:04 PM Peter Eisentraut
wrote:
>
> On 03.05.22 08:50, Amul Sul wrote:
> >> Do you have any data that supports removing DirectionFunctionCall()
> >> invocations? I suppose some performance benefit could be expected, or
> >> what do you have in mind?
> >>
> > Not really,
On 03.05.22 08:50, Amul Sul wrote:
Do you have any data that supports removing DirectionFunctionCall()
invocations? I suppose some performance benefit could be expected, or
what do you have in mind?
Not really, the suggestion to avoid DirectionFunctionCall() is from Tom.
For a trial, I have
On Mon, May 2, 2022 at 8:23 PM Peter Eisentraut
wrote:
>
> On 22.04.22 14:26, Amul Sul wrote:
> > Yes, I think we can do cleanup to some extent. Attaching the
> > following patches that first intend to remove DirectFunctionCall as
> > much as possible:
>
> Do you have any data that supports
On 22.04.22 14:26, Amul Sul wrote:
Yes, I think we can do cleanup to some extent. Attaching the
following patches that first intend to remove DirectFunctionCall as
much as possible:
Do you have any data that supports removing DirectionFunctionCall()
invocations? I suppose some performance
On Fri, Mar 18, 2022 at 1:17 AM Greg Stark wrote:
>
> On Fri, 11 Mar 2022 at 15:17, Tom Lane wrote:
> >
> > Amul Sul writes:
>
> > > Yeah, that's true, I am too not sure if we really need to refactor
> > > all those; If we want, I can give it a try.
> >
> > The patch as-presented isn't very
On Thu, Mar 17, 2022 at 4:02 PM Tom Lane wrote:
> Pretty much, yeah. I'm way more interested in cleaning up the code
> we have than in making things prettier for hypothetical future
> call sites. In particular, the problem with writing an API in a
> vacuum is that you have little evidence that
Greg Stark writes:
> On Fri, 11 Mar 2022 at 15:17, Tom Lane wrote:
>> The patch as-presented isn't very compelling for
>> lack of callers of the new function
> Tom, are you saying you think we're not interested in just adding this
> function unless it's part of this refactoring?
Pretty much,
On Fri, 11 Mar 2022 at 15:17, Tom Lane wrote:
>
> Amul Sul writes:
> > Yeah, that's true, I am too not sure if we really need to refactor
> > all those; If we want, I can give it a try.
>
> The patch as-presented isn't very compelling for
> lack of callers of the new function
Tom, are you
Amul Sul writes:
> On Wed, Feb 16, 2022 at 4:50 PM Peter Eisentraut
> wrote:
>> On 16.02.22 06:00, Amul Sul wrote:
>>> Currently, numeric_pg_lsn is the only one that accepts the Numeric
>>> value and converts to uint64 and that is the reason all the type
>>> conversion code is embedded into it.
On Wed, Feb 16, 2022 at 4:50 PM Peter Eisentraut
wrote:
>
> On 16.02.22 06:00, Amul Sul wrote:
> > Currently, numeric_pg_lsn is the only one that accepts the Numeric
> > value and converts to uint64 and that is the reason all the type
> > conversion code is embedded into it.
>
> There are other
On 16.02.22 06:00, Amul Sul wrote:
Currently, numeric_pg_lsn is the only one that accepts the Numeric
value and converts to uint64 and that is the reason all the type
conversion code is embedded into it.
There are other functions such as numeric_int8() that work similarly.
If you are going to
Hi,
Currently, numeric_pg_lsn is the only one that accepts the Numeric
value and converts to uint64 and that is the reason all the type
conversion code is embedded into it.
I think it would be helpful if that numeric-to-uint64 conversion code
is extracted as a separate function so that any other
14 matches
Mail list logo
