but we need to find a way to make this generic so that
custom types can define formatting rules for themselves.
--
Vik Fearing
r example, if the source or target is a composite, array,
or polymorphic type.
The standard is strict on what types can be cast to another, but I see
no reason not to be more generic.
--
Vik Fearing
On 25/07/2025 14:55, Matheus Alcantara wrote:
On Mon Jul 21, 2025 at 7:11 PM -03, Vik Fearing wrote:
SELECT a, b, c
FROM tab
QUALIFY wf() OVER () = ?
can be rewritten as:
SELECT a, b, c
FROM (
SELECT a, b, c, wf() OVER () = ? AS qc
FROM tab
) AS q
WHERE qc
and then let the
tests
Just a small cosmetic gripe, the regression test comments are usually
"-- ok" and "--fail", and not "-- Should error".
No comment on the rest of the patch.
--
Vik Fearing
the DEFAULT value to the requested
type is raised as an error.
--
Vik Fearing
please check the attached regress test and tests expected result.
Except for the weird restriction on the default value, this all looks
good to me (with the usual caveat that I am not an expert in C).
Are you planning to also implement the ?
--
Vik Fearing
out the QUALIFY clause as written in a
view and not as transformed. If we are going to go down the syntax
transformation route, that should happen in the rewriter at
planning/execution time.
--
Vik Fearing
comes clear that it will be
standardized (because so many other RDBMSes have it too).
Good advice.
--
Vik Fearing
that they can both operate on a window frame. Otherwise the
difference is night and day. Especially when you consider nested window
clauses (that postgres does not support yet).
I agree that its own clause is best; I just greatly dislike QUALIFY.
Sorry.
--
Vik Fearing
On 22/07/2025 14:26, Vik Fearing wrote:
The is:
::=
ERROR
| NULL
| DEFAULT
but I am planning on removing the NULL variant in favor of having the
be a . So
it would be either ERROR ON CONVERSION ERROR (postgres's current
behavior), or DEFAULT NULL ON CONVERSION
On 22/07/2025 12:19, jian he wrote:
On Tue, Jul 22, 2025 at 2:45 PM Vik Fearing wrote:
It was accepted into the standard after 2023 was released. I am the
author of this change in the standard, so feel free to ask me anything
you're unsure about.
is the generally syntax as mention
released. I am the
author of this change in the standard, so feel free to ask me anything
you're unsure about.
--
Vik Fearing
On 21/07/2025 23:29, Matheus Alcantara wrote:
On Mon Jul 21, 2025 at 5:23 PM -03, Vik Fearing wrote:
On 21/07/2025 14:47, Matheus Alcantara wrote:
Hi all,
I'm sending a proof-of-concept patch to add support for the QUALIFY
clause in Postgres. This feature allows filtering rows after w
il the standard accepts it, but
having a working patch ready to go seems like a good idea.
--
Vik Fearing
brief look at this, and I think your grammar is wrong.
The QUALIFY clause should go after the WINDOW clause, just like
FROM/WHERE and GROUP BY/HAVING.
That is what I am proposing to the standards committee, and I already
have some buy-in for that.
--
Vik Fearing
. I have recently revived that paper so hopefully it
will be accepted within the next year. I would even like to push so
that we have it in 19.
--
Vik Fearing
On 08/07/2025 02:37, Tom Lane wrote:
Vik Fearing writes:
Having read through this thread, is there any chance at all that we
might be able to implement feature F555, “Enhanced seconds precision”?
Don't see how we could do that without an on-disk compatibility break
for timestamps.
seconds precision”?
I feel we may have dug ourselves into a hole with integer timestamps
that span ridiculously long ranges.
--
Vik Fearing
has a strong
potential to break anything that reads psql output --- and I'd
urge you to think that human consumers of psql output may well
be the minority. There's an awful lot of scripts out there.
You mean scripts that don't use --no-psqlrc? Those scripts are already
bug ridden.
--
Vik Fearing
easier.
I am not against this at all, but what is the actual use case?
--
Vik Fearing
ient. Tags get even more granular while this provides
high-level draft/non-draft delineation where drafts don’t have to keep
being shuffled around. Review Need still needs review no matter where
it is. That doesn’t change.
+1
--
Vik Fearing
On 19/06/2025 16:47, Peter Eisentraut wrote:
On 17.06.25 17:37, Vik Fearing wrote:
For (which includes LOWER() and UPPER()), the text says in
Section 6.35 GR 7.e:
If the character set of is UTF8, UTF16, or UTF32,
then FR is replaced by
Case:
i) If the S IS NORMALIZED
On 17/06/2025 20:14, Jeff Davis wrote:
On Tue, 2025-06-17 at 17:37 +0200, Vik Fearing wrote:
If the character set of is UTF8, UTF16, or UTF32,
then FR is replaced by
Case:
i) If the S IS NORMALIZED evaluates to
True, then NORMALIZE (FR)
ii) Otherwise, FR.
I read
argument.
It does not appear to me that our LOWER and UPPER functions obey this
rule, so there is a valid argument that we should continue to ignore it.
Or, we can say that we have at least one of three compliant.
--
Vik Fearing
way back into the standard.
--
Vik Fearing
On 16/05/2025 23:21, Tom Lane wrote:
Vik Fearing writes:
On 16/05/2025 15:01, Tom Lane wrote:
Seems to me the obvious answer is to extend TABLESAMPLE (or at least, some
of the tablesample methods) to allow it to work on a subquery.
Isn't this a job for ?
FETCH SAMPLE FIRST 10 ROWS
ST 10 ROWS ONLY
Then the nodeLimit could do some sort of reservoir sampling.
There are several enhancements to coming down the
pipe, this could be one of them.
--
Vik Fearing
not be added to the syntax and
allow jsonpath to throw the error if the function doesn't exist?
--
Vik Fearing
tomer(Customer_ID)) stored;
This is lying to the planner, and you get to enjoy whatever breaks
because of it. A function that accesses external data is not immutable;
it is stable at best.
--
Vik Fearing
On 21/12/2024 05:23, Tom Lane wrote:
Vik Fearing writes:
Could I perhaps propose a sort of wildmat[1] syntax?
The above sequence could be expressed simply as:
LISTEN *,!foo.*,foo.bar.*
That doesn't absolve you from having to say what happens if the
user then issues another "
ot;, and also to all channels not beginning
"foo".
Could I perhaps propose a sort of wildmat[1] syntax?
The above sequence could be expressed simply as:
LISTEN *,!foo.*,foo.bar.*
I would like this in psql's backslash commands, too.
[1] https://en.wikipedia.org/wiki/Wildmat
--
Vik Fearing
On 02/12/2024 17:56, Tom Lane wrote:
Vik Fearing writes:
On 02/12/2024 03:15, Tom Lane wrote:
Also, if SQL intended to constrain the search path for unqualified
identifiers to be only the new schema, they'd hardly need a concept
of at all.
I looked up the original paper (MUN-051)
an order for searching for an SQL-invoked routine."
I can find nowhere that says that the path can or cannot be used for
other objects.
--
Vik Fearing
56c77...@postgresfriends.org
--
Vik Fearing
ween them. For example:
MATCH (c) -[:lbl]-> (d)
can be written as
MATCH (c) -
[:lbl] -
/* a comment here */
> (d)
Is that intentional?
I will continue to review this feature from the user's perspective.
Thank you for working on it, I am very excited to get this in.
--
Vik Fearing
.
--
Vik Fearing
ous row.
2. evaluate "col + 1" at the current row (that was previous row).
3. return the result.
If my understanding is correct, prev(price + 1) has the same meaning
as prev(price) + 1.
This is how I read the specification also.
--
Vik Fearing
t will become a lot more common with WITHOUT OVERLAPS, so I think it is
important to fix this at the same time or earlier as that feature.
Since this is quite broken and does not have any real world usefulness I
think we should just go ahead and disallow it and have a few people
complain.
+1
--
Vik Fearing
OVER () FROM planets; -- fails
ERROR: aggregate functions do not accept RESPECT/IGNORE NULLS
I believe they should both fail.
--
Vik Fearing
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 sta
t value without considering the constraints of
a domain is a bug that needs to be fixed in the standard.
--
Vik Fearing
the
same, but I would have to research that.
--
Vik Fearing
HISTCONTROL=ignoredups
will do the trick.
https://www.postgresql.org/docs/current/app-psql.html#APP-PSQL-VARIABLES-HISTCONTROL
--
Vik Fearing
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
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
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
version 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 o
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
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
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
ing
views) 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 this
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
the null value to be stored in a column of a base table
whose domain specifies NOT NULL is frankly a bug.
--
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
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
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
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
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 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
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
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 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
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
. 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
^
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
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
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
#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
) 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-de
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
s plausible.
Let us not engage in victim blaming. Postgres is the problem here.
--
Vik Fearing
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
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
rk everything all visible and all frozen
because it will copy over dead tuples that concurrent transactions are
still allowed to see.
--
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
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
trying 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
r xml features is necessary.
--
Vik Fearing
second command, it becomes
ambiguous. 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
installed; 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
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
OLUMN ] 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
1 - 100 of 473 matches
Mail list logo
