rivial patch for this a while ago but it
appears I never posted it. I will post that in a new thread so as not
to confuse the bots.
--
Vik Fearing
Infinite Interval thread, and so
here it is.
--
Vik Fearingcommit 5178a17a3280bc0018194e590d1b9fb3afbe3b65
Author: Vik Fearing
Date: Tue Jun 7 00:22:21 2022 +0200
allow +infinity for dates
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index fdffba4442..863ab84442
On 1/1/23 03:10, Vik Fearing wrote:
It has always annoyed me that we can't write '+infinity' for dates and
timestamps and get the OCD satisfaction of making our queries line up
with '-infinity'.
I wrote a fix for that some time ago but apparently never posted it.
On 1/1/23 20:21, Tom Lane wrote:
Vik Fearing writes:
Hmm. Somehow the .out test files were not included.
Fixed with attached.
Somehow you'd managed to duplicate some of the other changes,
so the cfbot still didn't like that :-(
Anyway, pushed with cosmetic changes. Notably, I le
re, I cannot guarantee that it will get accepted but I
will be arguing for it.
I don't think we should add that syntax until I do get it through the
committee, just in case they change something.
--
Vik Fearing
, (1, 2, 2), (1, 2, 1)) as abcd (a, b, c)
order by a, b, c;
a | b | c | rank
---+---+---+--
1 | 2 | 1 |1
1 | 2 | 1 |1
1 | 2 | 2 |3
(3 rows)
--
Vik Fearing
Key: enroll_date DESC
+ -> Seq Scan on empsalary
+(8 rows)
+
Why aren't min() and sum() calculated on the same WindowAgg run?
--
Vik Fearing
On 1/8/23 18:05, Ankit Kumar Pandey wrote:
On 08/01/23 21:36, Vik Fearing wrote:
On 1/8/23 11:21, Ankit Kumar Pandey wrote:
Please find attached patch with addressed issues mentioned before.
I am curious about this plan:
+-- ORDER BY's in multiple Window functions can be com
aps
make a MERGING() function analogous to the GROUPING() function that goes
with grouping sets?
MERGE ...
RETURNING *, MERGING('clause'), MERGING('action');
Or something.
--
Vik Fearing
On 1/12/23 18:14, Tom Lane wrote:
Pretty much the only available syntax space is curly braces,
and I don't really want to give those up for this either.
(One has to assume that the SQL committee has their eyes
on those too.)
They are used in row pattern recognition.
--
Vik Fearing
On 1/18/23 16:55, Tom Lane wrote:
Peter Eisentraut writes:
On 05.12.22 21:18, Vik Fearing wrote:
On 12/5/22 15:57, Vik Fearing wrote:
The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
returns an implementation-dependent (i.e. non-deterministic) value
from the rows in its
On 1/18/23 16:06, Peter Eisentraut wrote:
On 05.12.22 21:18, Vik Fearing wrote:
On 12/5/22 15:57, Vik Fearing wrote:
The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
returns an implementation-dependent (i.e. non-deterministic) value
from the rows in its group.
PFA an
cceptable or not.
For me, this is perfectly okay. Keep them at the lowest level of
reservation as possible.
--
Vik Fearing
, and "\dt *.*" showing all.
Hm, I could get on board with that -- any other opinions?
+1
--
Vik Fearing
r people think?
I vote for (B).
--
Vik Fearing
nting that
change.
So I am in favor of a pgindent run *at least* at the end of each
commitfest, giving a full month for patch authors to rebase before the
next fest.
--
Vik Fearing
is a base type that is not a numeric), so I prefer Tom's suggestion.
--
Vik Fearing
On 10/22/23 09:50, sirisha chamarthi wrote:
Is there any specific reason hot_standby_feedback default is set to off?
Yes. No one wants a rogue standby to ruin production.
--
Vik Fearing
On 10/23/23 04:02, sirisha chamarthi wrote:
On Sun, Oct 22, 2023 at 4:56 AM Vik Fearing wrote:
On 10/22/23 09:50, sirisha chamarthi wrote:
Is there any specific reason hot_standby_feedback default is set to off?
Yes. No one wants a rogue standby to ruin production.
Agreed.
Okay
On 10/23/23 20:36, Isaac Morland wrote:
Also, where it says "Expressions evaluating to TRUE or UNKNOWN succeed":
Do we really mean "Expressions evaluating to TRUE or NULL succeed"?
No, UNKNOWN is the correct nomenclature for booleans.
--
Vik Fearing
The intention is, in my
view, clearly to check the constraints upon casting. What other
explanation is there since the result type is still the domain's base
type[*]?
[*] In the standard, not in our superior implementation of it.
--
Vik Fearing
On 10/24/23 21:10, Jeff Davis wrote:
Can we revisit the idea of a per-WHEN RETURNING clause?
For the record, I dislike this idea.
--
Vik Fearing
On 10/31/23 19:28, Jeff Davis wrote:
On Tue, 2023-10-31 at 12:45 +0100, Vik Fearing wrote:
On 10/24/23 21:10, Jeff Davis wrote:
Can we revisit the idea of a per-WHEN RETURNING clause?
For the record, I dislike this idea.
I agree that it makes things awkward, and if it creates grammatical
On 11/1/23 11:12, Dean Rasheed wrote:
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 o
version of the disclaimer in sql_features.txt as well.
--
Vik Fearing
On 11/3/23 17:14, Jim Jones wrote:
Hi Daniel, hi Vik,
Thanks a lot for the review!
On 03.11.23 16:45, Vik Fearing wrote:
We should put a short version of the disclaimer in sql_features.txt as
well.
You mean to add a disclaimer in the X038 entry? Something along these
lines perhaps?
X038
On 11/3/23 21:28, Jim Jones wrote:
On 03.11.23 19:05, Vik Fearing wrote:
I was thinking of something much shorter than that. Such as
X038 XMLText YES supported except for RETURNING
v6 attached includes this change and the doc addition from Daniel.
There are some typos in
s a copy of SQL:2016 maybe something was changed, but I would
be surprised
Nothing has changed here in SQL:2023 (or since).
--
Vik Fearing
HISTCONTROL=ignoredups
will do the trick.
https://www.postgresql.org/docs/current/app-psql.html#APP-PSQL-VARIABLES-HISTCONTROL
--
Vik Fearing
h character set Unicode and
whose second value is an SQL/JSON item. The first value of an
SQL/JSON member is called the key and the second value is called
the bound value.
— An SQL/JSON sequence is an ordered list of zero or more SQL/JSON
items.
--
Vik Fearing
g the equality operator for some ranges and the overlaps
operator for some other ranges in the same key.
I prefer the first option. That is: WITHOUT OVERLAPS applies only to
the column or expression it is attached to, and need not be last in line.
--
Vik Fearing
rk everything all visible and all frozen
because it will copy over dead tuples that concurrent transactions are
still allowed to see.
--
Vik Fearing
On 9/1/23 21:56, Paul Jungwirth wrote:
On 9/1/23 03:50, Vik Fearing wrote:
On 9/1/23 11:30, Peter Eisentraut wrote:
1) If I write UNIQUE (a, b, c WITHOUT OVERLAPS), does the WITHOUT
OVERLAPS clause attach to the last column, or to the whole column
list? In the SQL standard, you can only have
t who knows how many duplicate
names per schema are out there in the wild from people specifying their
own names.
I don't know what the project would think about doing B.
[1] SQL:2023-2 11.4 Syntax Rule 4
--
Vik Fearing
s plausible.
Let us not engage in victim blaming. Postgres is the problem here.
--
Vik Fearing
On 9/6/23 02:53, Tom Lane wrote:
Vik Fearing writes:
On 9/6/23 00:14, David G. Johnston wrote:
I'm not all that for either A or B since the status quo seems workable.
Pray tell, how is it workable? The view does not identify a specific
constraint because we don't obey the ru
On 9/6/23 05:40, Tom Lane wrote:
Vik Fearing writes:
On 9/6/23 02:53, Tom Lane wrote:
What solution do you propose? Starting to enforce the spec's rather
arbitrary requirement that constraint names be unique per-schema is
a complete nonstarter. Changing the set of columns in a spec-de
) FROM t0 GROUP BY t0.c1 HAVING t0.c0
Wrong. c1 is the primary key and so c0 is functionally dependent on it.
Grouping by the PK is equivalent to grouping by all of the columns in
the table.
--
Vik Fearing
#x27;B'. Lexicographic
ordering takes precedence, so we have to try "aab" first. Otherwise our
query could return different results compared to another implementation.
Your understanding is correct.
--
Vik Fearing
ad we follow POSIX EREs? I
think this is better for users unless RPR's REs has significant merit
for users.
This would get big pushback from me.
--
Vik Fearing
On 9/13/23 07:14, Tatsuo Ishii wrote:
I was looking for this but I only found ISO/IEC 19075-5:2021.
https://www.iso.org/standard/78936.html
Maybe 19075-5:2021 is the latest one?
Yes, probably. Sorry.
--
Vik Fearing
^
CONTEXT: invalid type name "inteval second”
Probably a typo and you meant 'interval second' which works.
No, that is precisely the point. The result should be null instead of
an error.
--
Vik Fearing
own Cirrus CI environment and everything checked out fine.
Thank you
Thank you for reviewing!
--
Vik Fearing
. documentation
Thanks for this patch that a lot of people want.
However, it does not seem to address the issue of how to handle the
dropped value being in the high key of an index. Until we solve that
problem (and maybe others), this kind of patch is insufficient to add
the feature.
--
Vik Fearing
tion is intentionally
omitted.
--
Vik Fearing
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 7d2032885e..f8d70cdaa0 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -6404,6 +6404,29 @@ AlterEnumStmt:
n->skipIfNewValExists = false;
$$ = (No
On 9/29/23 03:17, Tom Lane wrote:
Vik Fearing writes:
On 9/28/23 20:46, Tom Lane wrote:
We went through all these points years ago when the enum feature
was first developed, as I recall. Nobody thought that the ability
to remove an enum value was worth the amount of complexity it'd
e
y (or even fully) to be able to defer such a
constraint.
Is a deferred
constraint having those properties likely to be actually useful?
I believe the answer is yes.
--
Vik Fearing
On 10/2/23 20:07, Dagfinn Ilmari Mannsåker wrote:
Vik Fearing writes:
No one except you has said anything about this patch. I think it would
be good to commit it, wordsmithing aside.
FWIW I'm +1 on this patch,
Thanks.
and with Tom on dropping the "yet". To me it
makes i
On 9/29/23 09:27, Michael Paquier wrote:
On Sat, Sep 23, 2023 at 12:54:01AM +0200, Vik Fearing wrote:
On 9/22/23 23:46, cary huang wrote:
I think this feature can be a useful addition in dealing with time
zones. I have applied and tried out the patch, The feature works as
described and seems
On 10/3/23 17:44, Tom Lane wrote:
Vik Fearing writes:
On 10/2/23 20:07, Dagfinn Ilmari Mannsåker wrote:
FWIW I'm +1 on this patch,
Thanks.
and with Tom on dropping the "yet". To me it
makes it sound like we intend to implement it soon (fsvo).
I am not fundamentall
On 9/29/23 09:27, Michael Paquier wrote:
On Sat, Sep 23, 2023 at 12:54:01AM +0200, Vik Fearing wrote:
On 9/22/23 23:46, cary huang wrote:
I think this feature can be a useful addition in dealing with time
zones. I have applied and tried out the patch, The feature works as
described and seems
using AT LOCAL is correctly
reproduced by ruleutils.c.
The attached v4 changes the regression tests (and nothing else).
--
Vik Fearing
From 03273214f0320e347a0b012763dc82cd91ae6775 Mon Sep 17 00:00:00 2001
From: Vik Fearing
Date: Wed, 4 Oct 2023 15:46:38 +0100
Subject: [PATCH v4] Add support f
On 10/10/23 05:34, Michael Paquier wrote:
I am attaching a v5 that addresses the documentation bits, could you
look at the business with date.c?
Here is a v6 which hopefully addresses all of your concerns.
--
Vik Fearing
From 042ce9b581ca3b17afbf229d209ca59addb6c9a2 Mon Sep 17 00:00:00 2001
overed together, but I'm not the one writing the
patch.
Álvaro Herrera has put (and is still putting) immense effort into
turning NOT NULL into a CHECK constraint.
Honestly, I don't see why the two patches need to be combined.
--
Vik Fearing
ideas.
Why not? The standard does not mention indexes (although some
discussions last week might change that) so we can change the syntax for
it as we wish. Doing so would also allow us to use ALTER TABLE ...
USING INDEX for such things.
--
Vik Fearing
t I
did not think of psql tab completion at all.
These two patches are co-dependent and whichever goes in first the other
will need to be adjusted accordingly.
--
Vik Fearing
the null value to be stored in a column of a base table
whose domain specifies NOT NULL is frankly a bug.
--
Vik Fearing
On 10/13/23 02:44, Tom Lane wrote:
Vik Fearing writes:
On 10/12/23 15:54, Tom Lane wrote:
There's been some discussion of treating the output of such a join,
subselect, etc as being of the domain's base type not the domain
proper. That'd solve this particular issue since then
On 10/13/23 05:07, Michael Paquier wrote:
On Fri, Oct 13, 2023 at 02:20:59AM +0200, Vik Fearing wrote:
On 10/10/23 05:34, Michael Paquier wrote:
I am attaching a v5 that addresses the documentation bits, could you
look at the business with date.c?
Here is a v6
Thanks for the new version
On 10/13/23 06:31, Michael Paquier wrote:
On Fri, Oct 13, 2023 at 03:07:25AM +0200, Vik Fearing wrote:
The SQL committee already has another operator starting with AT which is AT
LOCAL.
The other patch was the reason why I looked at this one.
Thank you for updating and committing this
On 10/13/23 06:37, Tom Lane wrote:
Vik Fearing writes:
Regardless of what the spec may or may not say about v1.d, it still
remains that nulls should not be allowed in a *base table* if the domain
says nulls are not allowed. Not mentioned in this thread but the
constraints are also applied
ing
views) and the data type should be the one specified in the domain.
--
Vik Fearing
etion_force_quote = false;
+ matches = rl_completion_matches(text, complete_from_files);
+ }
else if (TailMatchesCS("\\h|\\help"))
COMPLETE_WITH_LIST(sql_commands);
After some opinions on the first issue and fixing the second, I think
this is good to be committed.
--
Vik Fearing
While reviewing the patch for \gf, I noticed that \gx does not have tab
completion for its optional filename. Trivial patch attached. I would
also suggest this be backpatched.
--
Vik Fearing
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index ae35fa4aa9..7252b6c4e6
On 3/26/20 10:49 AM, Pavel Stehule wrote:
> Hi
>
> čt 26. 3. 2020 v 17:45 odesílatel Vik Fearing
> napsal:
>
>> After some opinions on the first issue and fixing the second, I think
>> this is good to be committed.
>>
>
> Thank you for review
This patch
looks good to me.
I concur. And it matches my reading of the standard (apart from the
intentional derivation).
--
Vik Fearing
't
expressed an opinion either way yet.)
--
Vik Fearing
e already reserved in most shells.
If parens are going to be required, why don't we just add them to \g?
TABLE blah \g (format csv) filename
--
Vik Fearing
On 4/1/20 5:01 AM, Bruce Momjian wrote:
>
> Patch applied though PG 10, thanks.
Thanks!
--
Vik Fearing
and I vote strongly against it.
--
Vik Fearing
t Vik
stated that the SQL spec seemed to imply that you had to track all those
things.
The spec does not allow schema changes at all on a a system versioned
table, except to change the system versioning itself.
--
Vik Fearing
ition keys, which is good.
If we were to automatically turn that into a global unique index, user may be
using the feature without knowing and experiencing some performance impacts (to
account for extra uniqueness check in all partitions).
I disagree. A user does not need to know that a table is partitionned,
and if the user wants a unique constraint on the table then making them
type an extra word to get it is just annoying.
--
Vik Fearing
On 11/29/22 17:29, Laurenz Albe wrote:
On Tue, 2022-11-29 at 13:58 +0100, Vik Fearing wrote:
I disagree. A user does not need to know that a table is partitionned,
and if the user wants a unique constraint on the table then making them
type an extra word to get it is just annoying.
Hmm. But
DISTINCT column, otherwise, you just destroy the
tuplesort and rinse and repeat for the next aggregate.
>
This looks like way to go that would ensure main use case of portability
from Oracle.
The goal should not be portability from Oracle, but adherence to the
standard.
--
Vik Fearing
]
::=
ERROR
| NULL
| DEFAULT
Once/If I get that in, I will be pushing to get that syntax in postgres
as well.
--
Vik Fearing
The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
returns an implementation-dependent (i.e. non-deterministic) value from
the rows in its group.
PFA an implementation of this aggregate.
Ideally, the transition function would stop being called after the first
non-null was foun
On 12/5/22 15:57, Vik Fearing wrote:
The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
returns an implementation-dependent (i.e. non-deterministic) value from
the rows in its group.
PFA an implementation of this aggregate.
Here is v2 of this patch. I had forgotten to
that used reservoir
sampling to get an evenly distributed value from the inputs. Something
like that seems to be what you are looking for here. I don't see the
use case for adding it to core, though.
The use case for ANY_VALUE is compliance with the standard.
--
Vik Fearing
r use case for it? I will happily write a patch for it, and also
submit it to the SQL Committee for inclusion in the standard. I need to
justify why it's a good idea, though, and we would need to consider what
to do with nulls now that there is .
--
Vik Fearing
On 12/6/22 05:22, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 8:46 PM Vik Fearing wrote:
On 12/5/22 18:56, David G. Johnston wrote:
Also, maybe we should have any_value do something like compute a 50/50
chance that any new value seen replaces the existing chosen value,
instead
of
On 12/6/22 05:57, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing wrote:
I can imagine an optimization that would remove an ORDER BY clause
because it isn't needed for any other aggregate.
I'm referring to the query:
select any_value(v order by v) from (val
On 12/7/22 04:22, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 10:40 PM Vik Fearing wrote:
On 12/6/22 05:57, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing
wrote:
I can imagine an optimization that would remove an ORDER BY clause
because it isn't needed fo
On 12/8/22 06:48, David G. Johnston wrote:
On Wed, Dec 7, 2022 at 10:00 PM Vik Fearing wrote:
On 12/7/22 04:22, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 10:40 PM Vik Fearing
wrote:
On 12/6/22 05:57, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing
wrote
ot sure this is useful enough to break feature freeze for,
> but I'm +1 for investigating it for v15.
Just like we have a pseudo "$user" schema, could we have a pseudo
"$extension" catalog? That should avoid changing grammar rules too much.
CREATE TABLE unaccented_words (
word "$extension".citext.citext,
CHECK (word = "$extension".unaccent.unaccent(word)
);
--
Vik Fearing
On 4/15/21 12:18 AM, Mark Dilger wrote:
>
>
>> On Apr 14, 2021, at 2:47 PM, Vik Fearing wrote:
>>
>> On 4/14/21 7:36 PM, Tom Lane wrote:
>>> Mark Dilger writes:
>>>>> On Apr 13, 2021, at 3:26 PM, Tom Lane wrote:
>>>>> How
On 1/23/23 08:50, David Rowley wrote:
On Thu, 19 Jan 2023 at 06:01, Vik Fearing wrote:
Thank you for the review. Attached is a new version rebased to d540a02a72.
I've only a bunch of nit-picks, personal preferences and random
thoughts to offer as a review:
1. I'd be incline
umped by the committer.
Marked as Ready for Committer. Thanks for the patch!
--
Vik Fearing
course.
I haven't tested the patch yet, just read it.
Is there any reason to use BY DEFAULT over ALWAYS? I tend to prefer the
latter.
--
Vik Fearing
esent.
Also, the specification for ROW_NUMBER() is:
f) ROW_NUMBER() OVER WNS is equivalent to the :
COUNT (*) OVER (WNS1 ROWS UNBOUNDED PRECEDING)
So I don't think we need to test for anything at all and can
indiscriminately add or replace the frame with ROWS UNBOUNDED PRECEDING.
--
Vik Fearing
ey: pg_am.amname
-> Seq Scan on pg_catalog.pg_am
Output: amname
(9 rows)
--
Vik Fearing
CREATE TABLE likeamlike(
LIKE likeam1 INCLUDING ACCESS METHOD,
LIKE likeam2 INCLUDING ACCESS METHOD
);
At the very least, the documentation should say that the last one wins.
--
Vik Fearing
problem there as SELECT 1_a; is currently parsed as SELECT 1 AS _a; when
it should be parsed as SELECT 1_ AS a; or perhaps even as an error since
0x1_a would be a valid number with no alias.
(The standard does not allow identifiers to begin with _ but we do...)
--
Vik Fearing
On 9/8/21 3:14 PM, Tom Lane wrote:
> Vik Fearing writes:
>
>> Is there any hope of adding the optional underscores? I see a potential
>> problem there as SELECT 1_a; is currently parsed as SELECT 1 AS _a; when
>> it should be parsed as SELECT 1_ AS a; or perhaps even as
s no scrolling; or at least should.
On the other hand, if there is no optimization or other meaningful
difference between SCROLL and NO SCROLL, then we can just document it as
a no-op that is only provided for standard syntax compliance.
--
Vik Fearing
make it a reality.
I don't have the skills to work on either side of this, but I would like
to voice my support in favor of having this feature and I would be happy
to help test it on a user level (as opposed to reviewing code).
--
Vik Fearing
ll exist.
The way I read the spec, r2 would be destroyed along with its objects.
12.7 GR 30.b.i says to destroy all abandoned role authorization
descriptors, and r2 matches that according to my reading of 12.7 GR 7.
--
Vik Fearing
On 10/7/21 4:21 PM, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (v...@postgresfriends.org) wrote:
>> On 10/6/21 8:48 PM, Stephen Frost wrote:
>>> Consider that with what you're proposing, a user could execute the
>>> following series of entirely
uture.
>
> Let me know your thoughts; I personally find this to be useful, and would be
> a nicer way for some
> configs to be displayed in the postgresql.conf file.
As discussed on IRC, I am in favor of this improvement. (I have not yet
looked at the patch.)
--
Vik Fearing
?
We have reason to think that they won't care at all.
There is no RETURNING clause in Standard SQL, and the way they would do
this is:
SELECT ...
FROM OLD TABLE (
MERGE ...
) AS m
The rules for that for MERGE are well defined.
--
Vik Fearing
On 7/13/23 01:48, Jeff Davis wrote:
On Wed, 2023-07-12 at 03:47 +0200, Vik Fearing wrote:
There is no RETURNING clause in Standard SQL, and the way they would
do
this is:
SELECT ...
FROM OLD TABLE (
MERGE ...
) AS m
The rules for that for MERGE are well defined
201 - 300 of 475 matches
Mail list logo
