Hi,
On 3/3/23 6:53 PM, Robert Haas wrote:
On Fri, Mar 3, 2023 at 11:28 AM Drouvot, Bertrand
wrote:
Thanks for having looked at it!
+1. Committed.
Thanks!
Not a big deal, but the commit message that has been used is not 100% accurate.
Indeed, for gistxlogDelete, that's the other way arou
On Fri, Mar 3, 2023 at 1:09 PM Önder Kalacı wrote:
>
>>
>> 5.
>>
>> + /*
>> +* If index scans are disabled, use a sequential scan.
>> +*
>> +* Note that we do not use index scans below when enable_indexscan is
>> +* false. Allowing primary key or replica ident
On 2023-03-03 Fr 13:46, Tom Lane wrote:
I wrote:
We can easily do better, as attached, but I wonder which other
headers should get the same treatment.
After a bit of further research I propose the attached. I'm not
sure exactly what subset of ECPG headers is meant to be exposed
to clients, bu
Here I made new patch of feature, discussed above.
WAIT FOR procedure - waits for certain lsn on pause
==
Synopsis
==
SELECT pg_wait_lsn(‘LSN’, timeout) returns boolean
Where timeout = 0, will wait infinite without timeout
And if timeout = 1, then just check if lsn wa
On Sat, Mar 4, 2023 at 11:23 AM Keisuke Kuroda
wrote:
>
>Good catch.
>Of the reserved words that are special values of type Date/Time,
>'now', 'today', 'tomorrow', 'yesterday', and 'allballs',
>I get an error even before applying the patch.
Thanks for pointing this out. After taki
On Thu, 2023-03-02 at 09:13 -0500, Dave Cramer wrote:
> I'd like to open up this discussion again so that we can
> move forward. I prefer the GUC as it is relatively simple and as
> Peter mentioned it works, but I'm not married to the idea.
It's not very friendly to extensions, where the types ar
On Fri, Mar 03, 2023 at 01:38:05PM -0800, Jacob Champion wrote:
> > > With this particular dataset, I don't see much improvement with
> > > zstd:long.
> >
> > Yeah. I this could be because either 1) you already got very good
> > comprssion without looking at more data; and/or 2) the neighboring da
Andrew Dunstan writes:
> On 2023-03-03 Fr 13:46, Tom Lane wrote:
>> This is actually moving the inclusion-check goalposts quite far,
>> but HEAD seems to pass cleanly, and again we can always adjust later.
>> Any objections?
> LGTM
Pushed, thanks for looking.
regards, to
Attached is the described patch. I have two notes
after implementing it:
- It feels like a bit of an abstraction break to
set tmask without actually setting any fields in
tm.
- I'm not sure if we should hard code in those
three specific reserved keywords or set tmask
in the default case
On Fri, Mar 3, 2023, at 16:11, Dean Rasheed wrote:
> So IMO the results just don't justify such an extensive set of
> changes, and I think we should abandon this fixed buffer approach.
I agree. I was hoping it would be possible to reduce the invasiveness,
but I think it's difficult and probably no
On Wed, 2023-03-01 at 11:09 +0100, Peter Eisentraut wrote:
> When collation support was added to PostgreSQL, we added UCS_BASIC,
> since that could easily be mapped to the C locale.
Sorting by codepoint should be encoding-independent (i.e. decode to
codepoint first); but the C collation is just
Joseph Koshakow writes:
> - I'm not sure if we should hard code in those
> three specific reserved keywords or set tmask
> in the default case.
I think we should tread very carefully about disallowing inputs that
have been considered acceptable for 25 years. I agree with disallowing
numeri
Gilles Darold writes:
> But I disagree the use of --table-with-childs and
> --exclude-table-with-childs because we already have the --table and
> --exclude-table, and it will add lot of code where we just need a switch
> to include children tables.
I quite dislike the idea of a separate --with
On Sun, Mar 5, 2023 at 7:30 AM Jeff Davis wrote:
> Sorting by codepoint should be encoding-independent (i.e. decode to
> codepoint first); but the C collation is just strcmp, which is
> encoding-dependent. So is UCS_BASIC wrong today?
It's created for UTF-8 only, and UTF-8 sorts the same way as t
On Sat, Mar 4, 2023 at 1:56 PM Tom Lane wrote:
>
>I think we should tread very carefully about disallowing inputs that
>have been considered acceptable for 25 years. I agree with disallowing
>numeric fields along with 'epoch' and 'infinity', but for example
>this seems perfectly u
Joseph Koshakow writes:
> On Sat, Mar 4, 2023 at 1:56 PM Tom Lane wrote:
>> Why do you want to skip ValidateDate in some cases? If we've not
>> had to do that before, I don't see why it's a good idea now.
> This goes back to the abstraction break of
> setting tmask without updating tm. Certain
On Sat, Jan 28, 2023 at 3:39 AM vignesh C wrote:
> On Tue, 1 Nov 2022 at 16:40, Thomas Munro wrote:
> > Here's an attempt at that. There aren't actually any cases of uses of
> > this stuff in critical sections here, so perhaps I shouldn't bother
> > with that part. The part I'd most like some f
On Sat, Mar 4, 2023 at 2:48 PM Tom Lane wrote:
>
>Right. So really we ought to move the ValidateDate call as
>well as the next half-dozen lines about "mer" down into
>the subsequent "do additional checking" stanza. It's all
>only relevant to normal date specs.
>
>BTW, looking
Joseph Koshakow writes:
> On Mon, Dec 12, 2022 at 10:55 AM Joseph Koshakow wrote:
>> I just found another class of this bug that the submitted patch does
>> not fix. If the units are at the beginning of the string, then they are
>> also ignored. For example, `date 'm d y2020m11d3'` is also valid.
Dave Cramer
On Sat, 4 Mar 2023 at 11:35, Jeff Davis wrote:
> On Thu, 2023-03-02 at 09:13 -0500, Dave Cramer wrote:
> > I'd like to open up this discussion again so that we can
> > move forward. I prefer the GUC as it is relatively simple and as
> > Peter mentioned it works, but I'm not married
Peter Eisentraut writes:
> [ v2-0001-Remove-incidental-md5-function-uses-from-main-reg.patch ]
I've gone through this and have a modest suggestion: let's invent some
wrapper functions around encode(sha256()) to reduce the cosmetic diffs
and consequent need for closer study of patch changes. In t
Andres Freund writes:
> Just pushed the actual pg_stat_io view, the splitting of the tablespace test,
> and the pg_stat_io tests.
One of the test cases is flapping a bit:
diff -U3
/home/pg/build-farm-15/buildroot/HEAD/pgsql.build/src/test/regress/expected/stats.out
/home/pg/build-farm-15/buil
On Sat, Mar 4, 2023 at 4:05 PM Tom Lane wrote:
>
>I started to look at this, and soon noticed that while we have test
cases
>matching this sort of date input, there is no documentation for it.
The
>code claims it's an "ISO" (presumably ISO 8601) format, and maybe it is
>because it
On Sun, 2023-03-05 at 08:27 +1300, Thomas Munro wrote:
> It's created for UTF-8 only, and UTF-8 sorts the same way as the
> encoded code points, when interpreted as a sequence of unsigned char
> by memcmp(), strcmp() etc. Seems right?
Right, makes sense.
Though in principle, shouldn't someone us
On Sat, 2023-03-04 at 18:04 -0500, Dave Cramer wrote:
> Most of the clients know how to decode the builtin types. I'm not
> sure there is a use case for binary encode types that the clients
> don't have a priori knowledge of.
The client could, in theory, have a priori knowledge of a non-builtin
ty
Jeff Davis writes:
> On Sat, 2023-03-04 at 18:04 -0500, Dave Cramer wrote:
>> Most of the clients know how to decode the builtin types. I'm not
>> sure there is a use case for binary encode types that the clients
>> don't have a priori knowledge of.
> The client could, in theory, have a priori kn
Jeff Davis writes:
> On Sun, 2023-03-05 at 08:27 +1300, Thomas Munro wrote:
>> It's created for UTF-8 only, and UTF-8 sorts the same way as the
>> encoded code points, when interpreted as a sequence of unsigned char
>> by memcmp(), strcmp() etc. Seems right?
> Right, makes sense.
> Though in pr
On Sat, Mar 4, 2023 at 5:07 PM Tom Lane wrote:
> Jeff Davis writes:
> > On Sat, 2023-03-04 at 18:04 -0500, Dave Cramer wrote:
> >> Most of the clients know how to decode the builtin types. I'm not
> >> sure there is a use case for binary encode types that the clients
> >> don't have a priori kno
Hi,
I was debugging a planner problem on Postgres 14.4 the other day - and the
involved "bad" plan was including Memoize - though I don't necessarily
think that Memoize is to blame (and this isn't any of the problems recently
fixed in Memoize costing).
However, what I noticed whilst trying differ
On Sat, 4 Mar 2023 at 19:06, Tom Lane wrote:
> Jeff Davis writes:
> > On Sat, 2023-03-04 at 18:04 -0500, Dave Cramer wrote:
> >> Most of the clients know how to decode the builtin types. I'm not
> >> sure there is a use case for binary encode types that the clients
> >> don't have a priori knowl
On Fri, Mar 3, 2023 at 10:04 PM Amit Kapila wrote:
>
> On Fri, Mar 3, 2023 at 4:13 PM Bharath Rupireddy
> wrote:
> >
> > On Thu, Jan 19, 2023 at 8:36 AM Peter Smith wrote:
> > >
> > > On Wed, Jan 18, 2023 at 6:26 PM Bharath Rupireddy
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > logicalrep_r
31 matches
Mail list logo
