On 3/22/24 01:46, Tom Lane wrote:
Vik Fearing writes:
Anyway, I will bring this up with the committee and report back. My
proposed solution will be for CAST to check domain constraints even if
the input is NULL.
Please do not claim that that is the position of the Postgres project
On 3/22/24 00:17, Tom Lane wrote:
Vik Fearing writes:
On 3/21/24 15:30, Tom Lane wrote:
The SQL spec's answer to that conundrum appears to be "NULL is
a valid value of every domain, and if you don't like it, tough".
I don't see how you can infer this from the standard at all.
straints of
a domain is a bug that needs to be fixed in the standard.
--
Vik Fearing
that.
--
Vik Fearing
HISTCONTROL=ignoredups
will do the trick.
https://www.postgresql.org/docs/current/app-psql.html#APP-PSQL-VARIABLES-HISTCONTROL
--
Vik Fearing
f SQL:2016 maybe something was changed, but I would
be surprised
Nothing has changed here in SQL:2023 (or since).
--
Vik Fearing
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
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
of the disclaimer in sql_features.txt as well.
--
Vik Fearing
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
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 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
it. 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/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
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/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
is a base type that is not a numeric), so I prefer Tom's suggestion.
--
Vik Fearing
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
) and the data type should be the one specified in the domain.
--
Vik Fearing
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
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
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 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 we'd decide
we
ose domain specifies NOT NULL is frankly a bug.
--
Vik Fearing
ql 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
ndard 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
, 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
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
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
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 fundamental
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/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 it sou
) 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 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
entail
.
--
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;
$$ = (Node *) n;
}
+ | ALTER TYP
. 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
own Cirrus CI environment and everything checked out fine.
Thank you
Thank you for reviewing!
--
Vik Fearing
;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
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
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
to try "aab" first. Otherwise our
query could return different results compared to another implementation.
Your understanding is correct.
--
Vik Fearing
) 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
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-defined
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 rules on one
not engage in victim blaming. Postgres is the problem here.
--
Vik Fearing
s 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
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
and all frozen
because it will copy over dead tuples that concurrent transactions are
still allowed to see.
--
Vik Fearing
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
racter 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
to figure out how to make it use a secondary
font, but that might take me a while.
--
Vik Fearing
On 8/25/23 17:56, Chapman Flack wrote:
[0] https://wiki.postgresql.org/wiki/PostgreSQL_vs_SQL/XML_Standards
I was not aware of this page. What a wealth of information!
--
Vik Fearing
On 8/25/23 14:42, Jim Jones wrote:
Hi Vik
Thanks for reviewing my patch!
Thank you for writing it!
On 25.08.23 12:05, Vik Fearing wrote:
I am replying to this email, but my comments are based on the v2 patch.
Thank you for working on this, and I think this is a valuable
addition. However
features is necessary.
--
Vik Fearing
us. If we then decide that VIRTUAL should be the default, we
will break people's scripts.
--
Vik Fearing
orting, duplicate names in different variants, or names in the wrong order etc. (Our convention is given name followed by surname.)
I think these might be the same person:
Zhihong Yu
Zihong Yu
I did not spot any others.
--
Vik Fearing
; maybe adding some
non-default dependencies would help?
I am struggling to find documentation on how to build the pdfs with
meson. Any pointers?
--
Vik Fearing
this
convention be a bit more inclusive of other cultures. My proposed
solution is to list them the same way we do now, but also have in
parentheses or something their name in their native order and script.
--
Vik Fearing
] column_name SET EXPRESSION expression
I am surprised this is not in the standard already. I will go work on that.
--
Vik Fearing
On 8/15/23 07:53, Pavel Stehule wrote:
út 15. 8. 2023 v 7:48 odesílatel Vik Fearing
napsal:
On 8/14/23 15:37, Pavel Stehule wrote:
po 14. 8. 2023 v 15:09 odesílatel Erik Rijkers napsal:
I think so this can be +/- 40 lines of C code
It seems to me like a good candidate for an extension
). I am a little
bit disappointed that we don't have a generic base conversion function,
but even if we did I think these specialized functions would still be
useful.
No objection from me.
--
Vik Fearing
ray, only direction array->json is covered
I don't think we should be extending the old API when there are Standard
ways of doing the same thing. In fact, I would like to see the old way
slowly be deprecated.
I think so this can be +/- 40 lines of C code
It seems to me like a good candidate for an extension.
--
Vik Fearing
egate.html
--
Vik Fearing
PostgreSQL Major Contributors:
Stacey Haysler
Steve Singer
Congratulations to all, and well deserved!
--
Vik Fearing
--
A |0 | 0
(1 row)
In this case, the pattern is B? instead of just B, which produces an
*empty match* for the MEASURES to be applied over.
--
Vik Fearing
stions/patches are welcome.
My own reviews will only focus on correctness for now. Once we get a
good set of regression tests all passing, I will focus more on
optimization. Of course, others might want to review the performance now.
Vik Fearing wrote:
I strongly disagree with this. Window funct
frame" are important concept to explain/understand
how PRP works.
If we are just using those terms for documentation, then okay.
--
Vik Fearing
as a "full" or "reduced" frame. The standard
uses those terms to explain the difference between before and after RPR
is applied, but window functions do not get to choose which frame they
apply over. They only ever apply over the reduced window frame.
--
Vik Fearing
WARNING or INFO? I see no reason to ERROR here.
--
Vik Fearing
extension (and possibly even core) functions that
don't handle the frame properly.
--
Vik Fearing
uple).
I have not tried this yet, though.
I don't understand this logic. Window functions work over a window
frame. What we are talking about here is *defining* a window frame.
How can a window function execute row pattern matching?
--
Vik Fearing
On 7/22/23 01:14, Jacob Champion wrote:
On 7/20/23 17:07, Vik Fearing wrote:
On 7/21/23 01:36, Jacob Champion wrote:
(I've attached two failing tests against v2, to hopefully better
illustrate, along with what I_think_ should be the correct results.)
Almost. You are matching 07-01-2023
better
illustrate, along with what I_think_ should be the correct results.)
Almost. You are matching 07-01-2023 but the condition is "price > 100".
--
Vik Fearing
ptions:
1. Backport patch[1] to 11,12,13
2. Change ONLY the limit on the max length of the password(my patch attached).
Please let me know your thoughts.
The third option is to upgrade.
--
Vik Fearing
dinal". There's the row_number()
function, for example.
There is also the WITH ORDINALITY and FOR ORDINALITY examples.
So perhaps pg_merge_when_clause_number() would
be a better name. It's still quite long, but it's the best I can think
of.
How about pg_merge_match_number() or pg_merge_
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
?
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/3/23 15:42, Daniel Gustafsson wrote:
On 6 Jun 2023, at 05:13, Vik Fearing wrote:
Patch against 3f1180 attached.
This patch fails to compile, the declaration of variables in the switch block
needs to be scoped within a { } block.
Interesting. It compiles for me.
I've fixed
made some
human errors. :-)
--
Vik Fearing
.
--
Vik Fearing
currently have on the code is you spelled PERMUTE as PREMUTE.
Everything else is hopefully explained above.
--
Vik Fearing
nk we can start
with a small subset of RPR then we could gradually enhance the
implementation.
I have no problem with that as long as we don't paint ourselves into a
corner.
Comments and suggestions are welcome.
I have not looked at the patch yet, but is the reason for doing R020
before R010 because you haven't done the MEASURES clause yet?
In any case, I will be watching this with a close eye, and I am eager to
help in any way I can.
--
Vik Fearing
ou show me an example of that happening with my patch?
--
Vik Fearing
On 6/6/23 03:56, Laurenz Albe wrote:
On Mon, 2023-06-05 at 23:13 -0400, Vik Fearing wrote:
The Standard defines time zone conversion as follows:
::=
[ ]
::=
AT
::=
LOCAL
| TIME ZONE
While looking at something else, I noticed we do not support AT LOCAL.
The local
in views where the view will
automatically adjust to the session's time zone.
Patch against 3f1180 attached.
--
Vik FearingFrom b8317f3070c11df1e2ad791bd8d823aaae66dbe4 Mon Sep 17 00:00:00 2001
From: Vik Fearing
Date: Mon, 5 Jun 2023 19:42:42 -0400
Subject: [PATCH v1] Add support
For me, this is perfectly okay. Keep them at the lowest level of
reservation as possible.
--
Vik Fearing
, we can just add that anyway. I think being
able to say
COLLATE UNICODE
instead of
COLLATE "und-x-icu"
or whatever it is, is pretty useful.
So, attached is a small patch to add this.
I don't feel competent to review the patch (simple as it is), but +1 on
the principl
.
Internally, all the numeric literal parsing of jsonpath goes through
numeric_in, which already supports all this, so this patch is just a bit
of lexer work and some tests.
Is T840 really NO after this patch?
--
Vik Fearing
in that order?), so I didn't think it was necessary. If others feel more
strongly, I can add those too.
No comment on adding names for everything, but a big +1 for the ones
included here.
--
Vik Fearing
"implementation-defined".
--
Vik Fearing
mp/restore. The
standard does not bother thinking about that.
--
Vik Fearing
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 inclined
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
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/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
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/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 combined
ll_date DESC
+ -> Seq Scan on empsalary
+(8 rows)
+
Why aren't min() and sum() calculated on the same WindowAgg run?
--
Vik Fearing
), (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
1 - 100 of 425 matches
Mail list logo
