On Wed, 15 May 2024 at 02:14, Erik Wienhold wrote:
>
> plpgsql fails to parse 1_000..1_000 as 1000..1000 in FOR loops:
>
> Fixed in the attached patch.
>
Nice catch! The patch looks good to me on a quick read-through.
I'll take a closer look next week, after the beta release, since it's
a v16+
On Thu, 16 May 2024 at 15:15, Peter Eisentraut wrote:
>
> I wonder if we can avoid making MERGE_ACTION a keyword.
>
Yeah, there was a lot of back and forth on this point on the original
thread, and I'm still not sure which approach is best.
> I think we could parse it initially as a function
On Tue, 14 May 2024 at 07:43, Michael Paquier wrote:
>
> On Tue, May 14, 2024 at 05:18:24AM +0200, Erik Wienhold wrote:
> > Parameter $1_2 is taken as $1 because in rule {param} in scan.l we get
> > the parameter number with atol which stops at the underscore. That's a
> > regression in
On Mon, 22 Apr 2024 at 06:04, Michael Paquier wrote:
>
> On Fri, Apr 19, 2024 at 12:47:43PM +0300, Aleksander Alekseev wrote:
> > Thanks. I see a few pieces of code that use special FOO_NUMBER enum
> > values instead of a macro. Should we refactor these pieces
> > accordingly? PFA another patch.
On Thu, 18 Apr 2024 at 13:00, Aleksander Alekseev
wrote:
>
> Fair point. PFA the alternative version of the patch.
>
Thanks. Committed.
Regards,
Dean
On Tue, 16 Apr 2024 at 11:35, Richard Guo wrote:
>
> On Tue, Apr 16, 2024 at 5:48 PM Aleksander Alekseev
> wrote:
>>
>> Oversight of 0294df2f1f84 [1].
>>
>> [1]:
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=0294df2f1f84
>
> +1. I think this change improves the code
On Wed, 27 Mar 2024 at 07:47, Jeff Davis wrote:
>
> This isn't a complete review, but I spent a while looking at this, and
> it looks like it's in good shape.
Thanks for looking.
> I like the syntax, and I think the solution for renaming the alias
> ("RETURNING WITH (new as n, old as o)") is a
On Tue, 26 Mar 2024 at 06:57, Dean Rasheed wrote:
>
> Based on the reviews so far, I think this is ready for commit, so
> unless anyone objects, I will do so in a day or so.
>
Committed. Thanks for the reviews.
Regards,
Dean
On Tue, 26 Mar 2024 at 07:30, Alvaro Herrera wrote:
>
> On 2024-Mar-25, Dean Rasheed wrote:
>
> > Also (not this patch's fault), psql doesn't seem to offer a way to
> > display domain constraint names -- something you need to know to drop
> > or alter them. Perha
On Thu, 21 Mar 2024 at 09:35, Dean Rasheed wrote:
>
> Trivial rebase forced by 6185c9737c.
>
I think it would be good to get this committed.
It has had a decent amount of review, at least up to v9, but a number
of things have changed since then:
1). Concurrent update behavio
On Tue, 27 Feb 2024 at 17:33, Dean Rasheed wrote:
>
> On Sat, 24 Feb 2024 at 17:10, Tomas Vondra
> >
> > I did a quick review and a little bit of testing on the patch today. I
> > think it's a good/useful idea, and I think the code is ready to go (the
> > code
On Fri, 22 Mar 2024 at 08:28, jian he wrote:
>
> On Thu, Mar 21, 2024 at 7:23 PM Peter Eisentraut wrote:
> >
> > Hmm. CREATE DOMAIN uses column constraint syntax, but ALTER DOMAIN uses
> > table constraint syntax. Attached is a patch to try to sort this out.
>
> also you should also change
On Wed, 20 Mar 2024 at 09:43, Peter Eisentraut wrote:
>
> On 19.03.24 10:57, jian he wrote:
> > this new syntax need to be added into the alter_domain.sgml's synopsis and
> > also
> > need an explanation varlistentry?
>
> The ALTER DOMAIN reference page refers to CREATE DOMAIN about the
>
On Tue, 19 Mar 2024 at 19:17, Ayush Vatsa wrote:
>
> > I'm marking this ready-for-commit (which I'll probably do myself in a
> > day or two, unless anyone else claims it first).
>
> Thank you very much, this marks my first contribution to the open-source
> community, and I'm enthusiastic about
On Tue, 19 Mar 2024 at 21:40, Tom Lane wrote:
>
> I'm inclined to leave that alone. The actual source sub-SELECT
> could only have had one column, so no real confusion is possible.
> Yeah, there's a resjunk grouping column visible in the plan as well,
> but those exist in many other queries, and
On Tue, 19 Mar 2024 at 16:42, Tom Lane wrote:
>
> Here's a hopefully-final version that makes that adjustment and
> tweaks a couple of comments.
>
This looks very good to me.
One final case that could possibly be improved is this one from aggregates.out:
explain (verbose, costs off)
select
On Sat, 16 Mar 2024 at 17:36, Ayush Vatsa wrote:
>
> Attached is the complete patch with all the required code changes.
> Looking forward to your review and feedback.
>
This looks good to me. I tested it and everything worked as expected.
I ran it through pgindent to fix some whitespace issues
On Mon, 18 Mar 2024 at 23:19, Tom Lane wrote:
>
> > Hm. I used "rescan(SubPlan)" in the attached, but it still looks
> > a bit odd to my eye.
>
> After thinking a bit more, I understood what was bothering me about
> that notation: it looks too much like a call of a user-defined
> function named
On Sun, 17 Mar 2024 at 19:39, Tom Lane wrote:
>
> Here's a cleaned-up version that seems to successfully resolve
> PARAM_EXEC references in all cases. I haven't changed the
> "(plan_name).colN" notation, but that's an easy fix once we have
> consensus on the spelling.
I took a more detailed
On Fri, 15 Mar 2024 at 17:14, Jeff Davis wrote:
>
> On Fri, 2024-03-15 at 11:20 +, Dean Rasheed wrote:
>
> > So barring any further objections, I'd like to go ahead and get this
> > patch committed.
>
> I like this feature from a user perspective. So +1 f
On Sat, 16 Mar 2024 at 17:25, Tom Lane wrote:
>
> After looking at your draft some more, it occurred to me that we're
> not that far from getting rid of showing "$n" entirely in this
> context. Instead of (subplan_name).$n, we could write something like
> (subplan_name).colN or
On Fri, 15 Mar 2024 at 11:06, Dean Rasheed wrote:
>
> Updated patch attached.
>
I have gone over this patch again in detail, and I believe that the
code is in good shape. All review comments have been addressed, and
the only thing remaining is the syntax question.
To recap, this add
Rebased version attached.
Regards,
Dean
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index f8f83d4..380d0c9
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -394,10 +394,14 @@
conditions for each action are re-evaluated on the updated version
On Wed, 13 Mar 2024 at 08:58, Dean Rasheed wrote:
>
> I think I'll go make those doc changes, and back-patch them
> separately, since they're not related to this patch.
>
OK, I've done that. Here is a rebased patch on top of that, with the
other changes you suggested.
Regards,
Dea
On Wed, 13 Mar 2024 at 06:44, jian he wrote:
>
>
> [ WITH with_query [, ...] ]
> MERGE INTO [ ONLY ]
> here the "WITH" part should have "[ RECURSIVE ]"
Actually, no. MERGE doesn't support WITH RECURSIVE.
It's not entirely clear to me why though. I did a quick test, removing
that restriction
While playing around with EXPLAIN and SubPlans, I noticed that there's
a bug in how this is handled for MERGE. For example:
drop table if exists src, tgt, ref;
create table src (a int, b text);
create table tgt (a int, b text);
create table ref (a int);
explain (verbose, costs off)
merge into
On Fri, 16 Feb 2024 at 19:39, Tom Lane wrote:
>
> > So now I'm thinking that we do have enough detail in the present
> > proposal, and we just need to think about whether there's some
> > nicer way to present it than the particular spelling I used here.
>
One thing that concerns me about making
On Thu, 7 Mar 2024 at 17:32, Alvaro Herrera wrote:
>
> This seems to work okay.
>
Yes, this looks good. I tested it against CREATE TABLE ... LIKE, and
it worked as expected. It might be worth adding a test case for that,
to ensure that it doesn't get broken in the future. Do we also want a
test
On Wed, 6 Mar 2024 at 22:22, Nathan Bossart wrote:
>
> Thanks for taking a look. I updated the synopsis sections in v3.
OK, that looks good. The vacuumdb synopsis in particular looks a lot
better now that "-N | --exclude-schema" is on its own line, because it
was hard to read previously, and
On Thu, 7 Mar 2024 at 13:00, Alvaro Herrera wrote:
>
> So I think the original developers of REPLICA IDENTITY had the right
> idea here (commit 07cacba983ef), and we mustn't change this aspect,
> because it'll lead to data corruption in replication. Using a deferred
> PK for DDL considerations
On Tue, 5 Mar 2024 at 13:55, Dean Rasheed wrote:
>
> > If I only execute merge , I will get the following error:
> > merge into tgt a using src1 c on a.a = c.a when matched then update
> > set b = c.b when not matched then insert (a,b) values(c.a,c.b); -- excute
&
On Wed, 6 Mar 2024 at 08:51, Peter Eisentraut wrote:
>
> For comparison with standard SQL (see ):
>
> For an INSERT you could write
>
> SELECT whatever FROM NEW TABLE (INSERT statement here)
>
> or for an DELETE
>
> SELECT whatever FROM OLD TABLE (DELETE statement here)
>
> And for an UPDATE
On Mon, 1 Jan 2024 at 13:28, Ayush Vatsa wrote:
>
> According to the documentation of pg_dump when the --extension option is not
> specified, all non-system extensions in the target database will get dumped.
> > Why do we need to explicitly exclude extensions?
> Hence to include only a few we
On Tue, 5 Mar 2024 at 02:22, Nathan Bossart wrote:
>
> I saw that this thread was referenced elsewhere [0], so I figured I'd take
> a fresh look. From a quick glance, I'd say 0001 and 0002 are pretty
> reasonable and could probably be committed for v17.
>
I'm not sure how useful these changes
On Tue, 5 Mar 2024 at 12:36, Alvaro Herrera wrote:
>
> Yeah. As I said upthread, a good fix seems to require no longer relying
> on RelationGetIndexAttrBitmap to obtain the columns in the primary key,
> because that function does not include deferred primary keys. I came up
> with the attached
[cc'ing Alvaro]
On Tue, 5 Mar 2024 at 10:04, zwj wrote:
>
> If I only execute merge , I will get the following error:
> merge into tgt a using src1 c on a.a = c.a when matched then update set
> b = c.b when not matched then insert (a,b) values(c.a,c.b); -- excute fail
> ERROR: MERGE
On Mon, 4 Mar 2024 at 12:34, Aleksander Alekseev
wrote:
>
> > This was an experimental patch, I was looking for the comment on the
> > proposed
> > approach -- whether we could simply skip the throwaway NOT NULL constraint
> > for
> > deferred PK constraint. Moreover, skip that for any PK
On Thu, 29 Feb 2024 at 09:50, Alvaro Herrera wrote:
>
> By all means let's get the feature out there. It's not a frequently
> requested thing but it does seem to come up.
>
Pushed. Thanks for reviewing.
Regards,
Dean
On Wed, 28 Feb 2024 at 09:16, jian he wrote:
>
> + oldcontext = MemoryContextSwitchTo(estate->es_query_cxt);
> +
> + node->as_epq_tupdesc = lookup_rowtype_tupdesc_copy(tupType, tupTypmod);
> +
> + ExecAssignExprContext(estate, >ps);
> +
> + node->ps.ps_ProjInfo =
> +
efault distribution, if omitted.
For different result datatypes, it ought to be mostly possible to
determine the result type from the arguments. There might be some
exceptions, like maybe "random_bytes(length)" to generate a byte
array, but I think that would be OK.
Regards,
Dean
From b1
On Fri, 23 Feb 2024 at 00:12, Tom Lane wrote:
>
> So after studying this for awhile, I see that the planner is emitting
> a PlanRowMark that presumes that the UNION ALL subquery will be
> scanned as though it's a base relation; but since we've converted it
> to an appendrel, the executor just
On Fri, 23 Feb 2024 at 14:35, Peter Eisentraut wrote:
>
> Various code comments say that the RangeTblEntry field inh may only be
> set for entries of kind RTE_RELATION.
>
> The function pull_up_simple_union_all() in prepjointree.c sets ->inh to
> true for RTE_SUBQUERY entries:
>
> /*
>
On Thu, 22 Feb 2024 at 03:46, zwj wrote:
>
> If I want to get the same results as Oracle, do I need to adjust the lock
> behavior of the update and merge statements?
> If I want to achieve the same results as Oracle, can I achieve exclusive
> locking by adjusting update and merge? Do you
On Tue, 20 Feb 2024 at 14:49, Dean Rasheed wrote:
>
> On the face of it, the simplest fix is to tweak is_simple_union_all()
> to prevent UNION ALL subquery pullup for MERGE, forcing a
> subquery-scan plan. A quick test shows that that fixes the reported
> issue.
>
>
On Tue, 20 Feb 2024 at 15:16, Tom Lane wrote:
>
> Dean Rasheed writes:
> > Looking at the script itself, the addition, subtraction,
> > multiplication and division tests at the top are probably pointless,
> > since I would expect those operations to be tested adequatel
On Tue, 20 Feb 2024 at 14:49, Dean Rasheed wrote:
>
> Also, if the concurrent update were an update of a key
> column that was included in the join condition, the re-scan would
> follow the update to a new matching source row, which is inconsistent
> with what would happen if
On Mon, 19 Feb 2024 at 17:48, zwj wrote:
>
> Hello,
>
>I found an issue while using the latest version of PG15
> (8fa4a1ac61189efffb8b851ee77e1bc87360c445).
>This question is about 'merge into'.
>
>When two merge into statements are executed concurrently, I obtain the
> following
On Mon, 19 Feb 2024 at 15:35, Tom Lane wrote:
>
> I thought I'd try to acquire some actual facts here, so I compared
> the code coverage shown by "make check" as of HEAD, versus "make
> check" after adding numeric_big to parallel_schedule. I saw the
> following lines of numeric.c as being
> > On 19 Feb 2024, at 12:48, Tom Lane wrote:
> >
> > Or we could just flush it. It's never detected a bug, and I think
> > you'd find that it adds zero code coverage (or if not, we could
> > fix that in a far more surgical and less expensive manner).
>
Off the top of my head, I can't say to
On Sun, 4 Feb 2024 at 18:19, zwj wrote:
>
>I found an issue while using the latest version of PG15
> (8fa4a1ac61189efffb8b851ee77e1bc87360c445).
>
>This issue is related to Megre into and other concurrent statements being
> written.
>I obtained different results in Oracle and PG
On Tue, 30 Jan 2024 at 12:47, Aleksander Alekseev
wrote:
>
> Maybe I'm missing something but I'm not sure if I understand what this
> test tests particularly:
>
> ```
> -- There should be no triple duplicates in 1000 full-range 32-bit random()
> -- values. (Each of the C(1000, 3) choices of
gly, the cfbot didn't pick up on the fact that it needed
rebasing. Anyway, the copyright years in the new file's header comment
needed updating, so here is a rebase doing that.
Regards,
Dean
From 15d0ba981ff03eca7143726fe7512adf00ee3a84 Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Fri, 25 Au
On Thu, 28 Dec 2023 at 07:34, jian he wrote:
>
> Your patch works.
> performance is the best amount for other options in [0].
> I don't have deep knowledge about which one is more random.
>
Thanks for testing.
> Currently we have to explicitly mention the lower and upper bound.
> but can we do
On Fri, 26 Jan 2024 at 15:57, Alvaro Herrera wrote:
>
> Well, firstly this is clearly a feature we want to have, even though
> it's non-standard, because people use it and other implementations have
> it. (Eh, so maybe somebody should be talking to the SQL standard
> committee about it). As for
n Fri, 26 Jan 2024 at 14:59, vignesh C wrote:
>
> CFBot shows that the patch does not apply anymore as in [1]:
>
Rebased version attached.
Regards,
Dean
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index f8f83d4..6ef0c2b
--- a/doc/src/sgml/mvcc.sgml
+++
On Mon, 22 Jan 2024 at 02:10, Peter Smith wrote:
>
> Hi, this patch was marked in CF as "Needs Review" [1], but there has
> been no activity on this thread for 6+ months.
>
> Is anything else planned? Can you post something to elicit more
> interest in the latest patch? Otherwise, if nothing
[cc'ing Joe]
On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote:
>
> Getting it print numeric/boolean without quotes was actually easy, as
> well as json(b). Implemented as the attached v2 patch.
>
> But: not quoting json means that NULL and 'null'::json will both be
> rendered as 'null'. That
On Tue, 9 Jan 2024 at 09:43, Christoph Berg wrote:
>
> I can see we probably wouldn't want two different output formats named
> json, but the general idea of "allow psql to format results as json of
> strings" makes a lot of sense, so we should try to make it work. Does
> it even have to be
On Thu, 7 Dec 2023 at 01:10, Joe Conway wrote:
>
> The attached should fix the CopyOut response to say one column.
>
Playing around with this, I found a couple of cases that generate an error:
COPY (SELECT 1 UNION ALL SELECT 2) TO stdout WITH (format json);
COPY (VALUES (1), (2)) TO stdout
On Mon, 18 Dec 2023 at 16:34, Jelte Fennema-Nio wrote:
>
> On Mon, 18 Dec 2023 at 16:38, Christoph Berg wrote:
> > We'd want both patches even if they do the same thing on two different
> > levels, I'd say.
>
> Makes sense.
>
I can see the appeal in this feature. However, as it stands, this
:00 2001
From: Dean Rasheed
Date: Fri, 25 Aug 2023 10:42:38 +0100
Subject: [PATCH v1] Add random-number-in-range functions.
This adds 3 functions:
random(min int, max int) returns int
random(min bigint, max bigint) returns bigint
random(min numeric, max numeric) returns numeric
I have been playing around with the idea of adding support for OLD/NEW
to RETURNING, partly motivated by the discussion on the MERGE
RETURNING thread [1], but also because I think it would be a very
useful addition for other commands (UPDATE in particular).
This was discussed a long time ago [2],
On Tue, 28 Nov 2023 at 03:42, Shubham Khanna
wrote:
>
> I reviewed the given Patch and it is working fine.
>
Thanks for checking. Patch pushed.
Regards,
Dean
On Mon, 14 Aug 2023 at 18:34, David Zhang wrote:
>
> it would be great to switch the order of the 3rd and the 4th line to make a
> better match for "CREATE" and "CREATE OR REPLACE" .
>
I took a look at this, and I think it's probably neater to keep the
"AS SELECT" completion for CREATE [OR
On Fri, 17 Nov 2023 at 04:30, jian he wrote:
>
> I think it should be:
> + You will require the SELECT privilege on any column(s)
> + of the data_source and
> + target_table_name referred to
> + in any condition or expression.
>
Ah, of course. As always, I'm blind to grammatical errors
On Mon, 13 Nov 2023 at 05:29, jian he wrote:
>
> v13 works fine. all tests passed. The code is very intuitive. played
> with multi WHEN clauses, even with before/after row triggers, work as
> expected.
>
Thanks for the review and testing!
> I don't know when replace_outer_merging will be
On Thu, 9 Nov 2023 at 12:49, Dean Rasheed wrote:
>
> OK, I have pushed 0001 and 0002. Here's the remaining (main) patch.
>
OK, I have now pushed the main patch.
Regards,
Dean
On Thu, 9 Nov 2023 at 18:55, Laurenz Albe wrote:
>
> I think it can be useful to allow a user an UPDATE where the result
> does not satisfy the USING clause of the FOR SELECT policy.
>
> The idea that an UPDATE should only produce rows you can SELECT is not
> true today: if you run an UPDATE
On Thu, 9 Nov 2023 at 15:16, Laurenz Albe wrote:
>
> I have thought some more about this, and I believe that if FOR SELECT
> policies are used to check new rows, you should be allowed to specify
> WITH CHECK on FOR SELECT policies. Why not allow a user to specify
> different conditions for
On Sun, 5 Nov 2023 at 11:52, Dean Rasheed wrote:
>
> OK, that's a fair point. Attached is a new version, replacing those
> parts of the implementation with a new MergingFunc node. It doesn't
> add that much more complexity, and I think the new code is much
> neater.
>
Rebase
On Thu, 9 Nov 2023 at 07:15, Ashutosh Bapat
wrote:
>
> Just to test whether that bug fix also fixes the failure seen with
> this patchset, I am attaching the patchset including the patch with
> the fix.
>
> 0001 - fix in other thread
> 0002 and 0003 are 0001 and 0002 in the previous patch set.
>
On Wed, 8 Nov 2023 at 06:56, jian he wrote:
>
> > On Tue, 7 Nov 2023 at 14:33, Dean Rasheed wrote:
> >
> > Ah, Windows Server didn't like that. Trying again with "INT64CONST(0)"
> > instead of just "0" in interval_um().
> >
> I found this
One of the new tests in the infinite interval patch has revealed a bug
in our 64-bit integer subtraction code. Consider the following:
select 0::int8 - '-9223372036854775808'::int8;
This should overflow, since the correct result (+9223372036854775808)
is out of range. However, on platforms
While working on the MERGE RETURNING patch, I noticed a pre-existing
MERGE bug --- ExecMergeMatched() should not call ExecUpdateEpilogue()
if ExecUpdateAct() indicates that it did a cross-partition update.
The immediate consequence is that it incorrectly tries (and fails) to
fire AFTER UPDATE ROW
On Wed, 1 Nov 2023 at 17:49, Jeff Davis wrote:
>
> Most of my concern is that parts of the implementation feel like a
> hack, which makes me concerned that we're approaching it the wrong way.
>
OK, that's a fair point. Attached is a new version, replacing those
parts of the implementation with a
On Tue, 31 Oct 2023 at 23:19, Vik Fearing wrote:
>
> On 10/31/23 19:28, Jeff Davis wrote:
>
> > Assuming we have one RETURNING clause at the end, then it creates the
> > problem of how to communicate which WHEN clause a tuple came from,
> > whether it's the old or the new version, and/or which
On Sat, 28 Oct 2023 at 09:35, jian he wrote:
>
> hi.
> Excellent work! regress test passed! The code looks so intuitive!
>
Thanks for looking!
> doc/src/sgml/ref/create_view.sgml.
> Do we need to add
> If the view or any of its base
> relations has an
On Wed, 25 Oct 2023 at 02:07, Merlin Moncure wrote:
>
> On Tue, Oct 24, 2023 at 2:11 PM Jeff Davis wrote:
>>
>> Can we revisit the idea of a per-WHEN RETURNING clause? The returning
>> clauses could be treated kind of like a UNION, which makes sense
>> because it really is a union of different
On Fri, 27 Oct 2023 at 13:56, Ashutosh Bapat
wrote:
>
> Should we change this to call INTERVAL_NOBEGIN() to be added by
> infinite interval patches?
>
Given that this is a bug that can lead to incorrect query results, I
plan to back-patch it, and INTERVAL_NOBEGIN() wouldn't make sense in
In contrib/btree_gin, leftmostvalue_interval() does this:
leftmostvalue_interval(void)
{
Interval *v = palloc(sizeof(Interval));
v->time = DT_NOBEGIN;
v->day = 0;
v->month = 0;
return IntervalPGetDatum(v);
}
which is a long way short of the minimum possible interval value.
On Wed, 4 Oct 2023 at 14:29, Ashutosh Bapat
wrote:
>
> I think we should introduce interval_out_of_range_error() function on
> the lines of float_overflow_error(). Later patches introduce more
> places where we raise that error. We can introduce the function as
> part of those patches.
>
I'm not
On Tue, 24 Oct 2023 at 09:36, Laurenz Albe wrote:
>
> I'd say that this error is wrong. The FOR SELECT policy should be applied
> to the WHERE condition, but certainly not to check new rows.
>
Yes, I had the same thought recently. I would say that the SELECT
policies should only be used to
On Thu, 19 Oct 2023, 05:32 Ashutosh Bapat,
wrote:
> On Wed, Oct 18, 2023 at 8:23 PM Tomas Vondra
> wrote:
>
> >
> > I did use that many values to actually force "compaction" and merging of
> > points into ranges. We only keep 32 values per page range, so with 2
> > values we'll not build a
On Wed, 18 Oct 2023 at 09:16, Tomas Vondra
wrote:
>
> BTW when adding the tests with extreme values, I noticed this:
>
> test=# select '5874897-01-01'::date;
>date
> ---
>5874897-01-01
> (1 row)
>
> test=# select '5874897-01-01'::date + '1 second'::interval;
>
On Tue, 17 Oct 2023 at 21:25, Tomas Vondra
wrote:
>
> Here's a couple cleaned-up patches fixing the various discussed here.
> I've tried to always add a regression test demonstrating the issue
> first, and then fix it in the next patch.
>
This looks good to me.
> 2) incorrect subtraction in
On Fri, 13 Oct 2023 at 13:17, Tomas Vondra
wrote:
>
> I do plan to backpatch this, yes. I don't think there are many people
> affected by this (few people are using infinite dates/timestamps, but
> maybe the overflow could be more common).
>
OK, though I doubt that such values are common in
On Fri, 13 Oct 2023 at 11:44, Tomas Vondra
wrote:
>
> On 10/13/23 11:21, Dean Rasheed wrote:
> >
> > Is this only inefficient? Or can it also lead to wrong query results?
>
> I don't think it can produce incorrect results. It only affects which
> values we "merge
On Thu, 12 Oct 2023 at 23:43, Tomas Vondra
wrote:
>
> Ashutosh Bapat reported me off-list a possible issue in how BRIN
> minmax-multi calculate distance for infinite timestamp/date values.
>
> The current code does this:
>
> if (TIMESTAMP_NOT_FINITE(dt1) || TIMESTAMP_NOT_FINITE(dt2))
>
On Mon, 2 Oct 2023 at 01:01, Tom Lane wrote:
>
> Erwin Brandstetter writes:
> > On Mon, 2 Oct 2023 at 00:33, Dean Rasheed wrote:
> >> The only place that exposes the eref's made-up relation name is the
> >> existing query deparsing code in ruleutils.c, which uniqui
On Fri, 22 Sept 2023 at 08:49, Ashutosh Bapat
wrote:
>
> Following code in ExecInterpExpr makes it clear that the
> deserialization function is be executed in per tuple memory context.
> Whereas the aggregate's context is different from this context and may
> lives longer that the context in
On Wed, 20 Sept 2023 at 15:00, Ashutosh Bapat
wrote:
>
> 0005 - Refactored Jian's code fixing window functions. Does not
> contain the changes for serialization and deserialization. Jian,
> please let me know if I have missed anything else.
>
That looks a lot neater. One thing I don't care for
On Wed, 20 Sept 2023 at 13:09, Dean Rasheed wrote:
>
> So basically, do_interval_accum() could be simplified to:
>
Oh, and I guess it also needs an INTERVAL_NOT_FINITE() check, to make
sure that finite values don't sum to our representation of infinity,
as in interval_pl().
Regards,
Dean
On Wed, 20 Sept 2023 at 11:27, jian he wrote:
>
> if I remove IntervalAggState's element: MemoryContext, it will not work.
> so I don't understand what the above sentence means.. Sorry. (it's
> my problem)
>
I don't see why it won't work. The point is to try to simplify
do_interval_accum()
On Sat, 16 Sept 2023 at 01:00, jian he wrote:
>
> I refactor the avg(interval), sum(interval), so moving aggregate,
> plain aggregate both work with +inf/-inf.
> no performance degradation, in fact, some performance gains.
>
I haven't reviewed this part in any detail yet, but I can confirm that
On Fri, 15 Sept 2023 at 08:00, vignesh C wrote:
>
> On Thu, 14 Sept 2023 at 15:33, Himanshu Upadhyaya
> wrote:
> >
> > On Thu, Sep 14, 2023 at 9:57 AM vignesh C wrote:
> >>
> >> postgres=*# SET CONSTRAINTS tbl_chk_1 DEFERRED;
> >> SET CONSTRAINTS
> >> postgres=*# INSERT INTO tbl values (1);
>
On Wed, 13 Sept 2023 at 11:13, Ashutosh Bapat
wrote:
>
> On Tue, Sep 12, 2023 at 2:39 PM Dean Rasheed wrote:
> >
> > and it looks like the infinite interval
> > input code is broken.
>
> The code required to handle 'infinity'
On Thu, 24 Aug 2023 at 14:51, Ashutosh Bapat
wrote:
>
> The patches still apply. But here's a rebased version with one white
> space error fixed. Also ran pgindent.
>
This needs another rebase, and it looks like the infinite interval
input code is broken.
I took a quick look, and had a couple
Updated version attached, fixing an uninitialized-variable warning
from the cfbot.
Regards,
Dean
diff --git a/doc/src/sgml/dml.sgml b/doc/src/sgml/dml.sgml
new file mode 100644
index cbbc5e2..7f65f6e
--- a/doc/src/sgml/dml.sgml
+++ b/doc/src/sgml/dml.sgml
@@ -283,10 +283,15 @@ DELETE FROM
On Tue, 25 Jul 2023 at 21:46, Gurjeet Singh wrote:
>
> There seems to be other use cases which need us to invent a method to
> expose a command-specific alias. See Tatsuo Ishii's call for help in
> his patch for Row Pattern Recognition [1].
>
I think that's different though, because in that
On Mon, 21 Aug 2023 at 20:15, Nathan Bossart wrote:
>
> I added some examples for negative inputs.
>
> I renamed it to to_bin().
>
> I reordered the functions in the docs.
>
OK, cool. This looks good to me.
Regards,
Dean
1 - 100 of 527 matches
Mail list logo
