the first two tags (which are likely the same code
path; I haven't looked) the same as the third? I can look into writing
the patch if desired.
--
Vik Fearing
f the table, but for postgres's heap there is no reason
not to prefer the natural key of the table.
My vote is with Tom on this one.
--
Vik Fearing
On 1/17/21 5:46 PM, Surafel Temesgen wrote:
> On Sat, Jan 16, 2021 at 10:12 PM Vik Fearing
> wrote:
>
>>
>> I haven't looked at this patch in a while, but I hope that ALTER TABLE t
>> ADD SYSTEM VERSIONING is not adding any columns. That is a bug if it does.
>>
On 1/17/21 10:41 AM, Noah Misch wrote:
> On Sat, Jan 16, 2021 at 02:05:43PM +0100, Vik Fearing wrote:
>> On 12/30/20 12:59 PM, Noah Misch wrote:
>>> On Tue, Dec 29, 2020 at 05:49:24AM -0800, Noah Misch wrote:
>>>> https://postgr.es/m/20201031163518.gb4039...@rfd.le
LE foo ADD SYSTEM
> VERSIONING
> is to add system versioning functionality to existing application
I haven't looked at this patch in a while, but I hope that ALTER TABLE t
ADD SYSTEM VERSIONING is not adding any columns. That is a bug if it does.
--
Vik Fearing
On 1/16/21 6:10 PM, Tom Lane wrote:
> Vik Fearing writes:
>> On 1/16/21 4:32 PM, Andreas Karlsson wrote:
>>> On 1/16/21 2:02 PM, Vik Fearing wrote:
>>>> I am in favor of such a change so that we can also accept 1_000_000
>>>> which currently parses as &
On 1/16/21 4:32 PM, Andreas Karlsson wrote:
> On 1/16/21 2:02 PM, Vik Fearing wrote:
>> I am in favor of such a change so that we can also accept 1_000_000
>> which currently parses as "1 AS _000_000" (which also isn't compliant
>> because identifiers cannot start
or this feature which implements all the
requirements of the standard (except syntax grammar, of course).
https://github.com/xocolatl/periods/
--
Vik Fearing
the validity times
I don't read the standard as being ambiguous about this at all. The
columns should be shown just like any other column of the table.
I am not opposed to being able to set an attribute on columns allowing
them to be excluded from "*" but that is irrelevant to this patch.
--
Vik Fearing
was unknown to some people here.
>
> [1]
> https://docs.oracle.com/cd/E93962_01/bigData.Doc/eql_onPrem/src/reql_statement_let.html
> [2]
> https://docs.couchbase.com/server/current/n1ql/n1ql-language-reference/let.html
> [3] https://asterixdb.apache.org/docs/0.9.3/sqlpp/manual.html#Let_clauses
>
> Kind regards,
>
> Joel
>
--
Vik Fearing
This ended up being simple. Attached.
>
> This is defective; it fails to reproduce nspacl after "ALTER SCHEMA public
> OWNER TO pg_write_server_files; REVOKE ALL ON SCHEMA public FROM
> pg_write_server_files;". I will try again later.
Could I ask you to also include COMMENTs when you try again, please?
--
Vik Fearing
ntial typos better. But if there is
> no interest, then that's fine.
I am in favor of such a change so that we can also accept 1_000_000
which currently parses as "1 AS _000_000" (which also isn't compliant
because identifiers cannot start with an underscore, but I don't want to
take it that far).
It would also allow us to have 0xdead_beef, 0o_777, and 0b1010__1110
without most of it being interpreted as an alias.
--
Vik Fearing
ht but the error messages are nonsensical to me.
I would like to see all user-facing instances of "WHEN AND" be replaced
by the admittedly more verbose "WHEN [NOT] MATCHED AND".
--
Vik Fearing
step = 0;
>
> When would the last else statement execute ? Since the above code is
> for WINDOW_SEEK_CURRENT, I wonder why step should be 0.
Hi.
"lag(expr, 0) over w" is useless but valid.
--
Vik Fearing
m a more general angle as well.
Could this work be salvaged to add the ability to ALTER a column to hide
it from star expansion? That's a feature I've often seen requested,
especially from people working with PostGIS's geometry.
Totally off-topic for this thread, though.
--
Vik Fearing
On 5/22/20 12:40 PM, Vik Fearing wrote:
>>> 2)
>>> This query is an infinite loop, as expected:
>>>
>>> with recursive a as (select 1 as b union all select b from a)
>>> table a;
>>>
>>> But it becomes an error when you add a cy
On 11/21/20 10:07 AM, Krasiyan Andreev wrote:
> Fixed patch attached, after new introduced conflicts.
> Vik, can you add it to the next commitfest, to be able to test it.
I have done this now. Thanks!
--
Vik Fearing
On 11/9/20 9:29 AM, Vik Fearing wrote:
> Hello,
>
> I've been doing some benchmarking on recent version of PostgreSQL and
> I'm seeing some regressions. The benchmark setup is as described in [1]
> except it looks like I got lucky in the runs used for that article.
>
> Af
TE AGGREGATE
> suggested in the original message, using the existing array_cat as the
> state transition function?
Nope. As my example showed.
One could imagine extending it with an inverse transition function for
use in windows (small w) but that's about it.
--
Vik Fearing
e or replace function bubu(a int, b int)
returns void as $$
<< b >>
begin
raise notice '% %', b.a, b.b;
end;
$$ language plpgsql;
That doesn't currently work, but it could be made to.
--
Vik Fearing
y_cat(a) from (values (array[1]), (array[2])) as v(a);
array_cat
-------
{1,2}
(1 row)
--
Vik Fearing
On 11/12/20 11:35 PM, Krasiyan Andreev wrote:
> Hi, it looks like Vik Fearing's patch does not apply anymore, because there
> are many conflicts with recent changes, fixed patch attached.
Thanks! I've been away from this list for a while and I have some
catching up to do.
--
Vik Fearing
ld we also take this opportunity to standardize
the comment itself? Even in your patch there is a mix of spacing and
casing.
My preference is /* EMPTY */. That is, uppercase with spaces, but
whatever gets chosen is fine with me.
--
Vik Fearing
started late in
October).
[1]
https://www.enterprisedb.com/blog/postgresql-tproc-c-benchmarks-postgresql-12-vs-postgresql-13-performance
--
Vik Fearing
and the
> fact that the outcome may result in a completely different patch, I'm inclined
> to mark this returned with feedback rather than have it linger. The
> discussion
> can continue and the entry be re-opened.
>
> Thoughts?
No objection.
--
Vik Fearing
On 7/1/20 10:34 PM, Pavel Stehule wrote:
> st 1. 7. 2020 v 22:31 odesílatel Vik Fearing
> napsal:
>
>> On 7/1/20 9:32 PM, Pavel Stehule wrote:
>>> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
>>> napsal:
>>>
>>>> On 7/1/20 3:36 PM, Rober
On 7/1/20 9:32 PM, Pavel Stehule wrote:
> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
> napsal:
>
>> On 7/1/20 3:36 PM, Robert Haas wrote:
>>> I actually don't have a very clear idea of what the standard has to
>>> say about SQL-language functions. Does it just
her a single sql statement, or a collection of them between
"begin atomic" and "end". There are no variables or flow control
constructs or anything like that, just as there are no such things
outside of a function.
(There are a few statements that are not allowed, such as COMMIT.)
--
Vik Fearing
]
https://www.postgresql.org/message-id/CAGMVOdsbtRwE_4%2Bv8zjH1d9xfovDeQAGLkP_B6k69_VoFEgX-A%40mail.gmail.com
--
Vik Fearing
>From 9ea72a4fe144f8ffdccb4b53eb4ea97e24ce61f7 Mon Sep 17 00:00:00 2001
From: Vik Fearing
Date: Sun, 31 May 2020 07:29:35 +0200
Subject: [PATCH 1/2] implement for win
guage design point of
> view[...]
Don't go there. There is nothing but pain there.
--
Vik Fearing
patch to add that.
The only thing that isn't dead-obvious about this patch is the commit
message says "[PATCH 1/2]". What is in the other part?
Assuming that's just a remnant of development, this LGTM.
--
Vik Fearing
t it's there so this is all LGTM.
Thanks for doing this!
--
Vik Fearing
ric column, because by definition it overflows any finite precision
> restriction. If we did that, you'd never see Inf in a
> standard-conforming column, since SQL doesn't allow unconstrained
> numeric columns IIRC.
It does. The precision and scale are both optional.
If the precision is missing, it's implementation defined; if the scale
is missing, it's 0.
--
Vik Fearing
in this area per [0].
These look straightforward to me.
Looking at that big table, I see everything is 0-based except the
quarter. That seems unfortunate, and if this were a new feature I'd
lobby to have it changed. I don't think we can do anything about it
now, though.
--
Vik Fearing
On 6/2/20 10:51 PM, Bruce Momjian wrote:
> On Tue, Jun 2, 2020 at 09:29:09PM +0200, Vik Fearing wrote:
>> On 6/2/20 7:25 PM, Bruce Momjian wrote:
>>> I think it would have been helpful if an email explaining this idea for
>>> discussion would have been posted b
On 6/2/20 7:25 PM, Bruce Momjian wrote:
> On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote:
>> On 5/27/20 7:27 AM, David G. Johnston wrote:
>>>> Would you propose we just error out in that case, or should we
>>>> silently enable the required o
ople don't qualify their
columns and I don't know the schema. We should turn that on by default,
as well.
--
Vik Fearing
for anyelement. Are you sure we don't want to give
at least the anycompatible type a nice public workout with this?
--
Vik Fearing
On 5/31/20 9:53 PM, Tom Lane wrote:
> Vik Fearing writes:
>> postgres=# SELECT LAG(n, 1, -99) OVER (ORDER BY n)
>> postgres-# FROM (VALUES (1.1), (2.2), (3.3)) AS v (n)
>> postgres-# ORDER BY n;
>> ERROR: function lag(numeric, integer, integer) does not exist
&
for other functions with a similar issue but didn't find any.
[1] https://twitter.com/pg_xocolatl/status/1266694496194093057
--
Vik Fearing
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7c06afd3ea..f1b6f6392e 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
On 5/27/20 7:27 AM, David G. Johnston wrote:
> On Tuesday, May 26, 2020, David Rowley wrote:
>
>> On Tue, 26 May 2020 at 23:59, Vik Fearing wrote:
>>> Are you saying we should have all new EXPLAIN options off forever into
>>> the future because apps won't know a
On 5/26/20 10:08 PM, Justin Pryzby wrote:
> If you want to change the default, I think that should be a separate
> patch/thread.
Yes, it will be.
--
Vik Fearing
, this argument doesn't hold. If an app wants something on or off,
it should say so. If it doesn't care, then it doesn't care.
Are you saying we should have all new EXPLAIN options off forever into
the future because apps won't know about the new data? I guess we
should also not ever introduce new plan nodes because those won't be
known either.
I'm not buying that.
--
Vik Fearing
On 5/25/20 6:40 PM, Tom Lane wrote:
> Vik Fearing writes:
>> On 5/25/20 3:28 PM, Peter Eisentraut wrote:
>>> I looked into this (changing the return types of date_part()/extract()
>>> from float8 to numeric).
>
>> I think what would be better is to have a spe
e extract translate to the appropriate one. This
is particularly interesting for epoch but it would also allow us to
return the correct type mandated by the spec.
(I would also accept a specific date_part per return type instead of per
part, that would probably even be better.)
--
Vik Fearing
on [, ...] ) ] statement
That has nothing to do with this patch.
--
Vik Fearing
On 5/23/20 6:23 PM, Pavel Stehule wrote:
> It's lot of new GUC variables. Isn't better only one that allows list of
> values?
I like this way better.
--
Vik Fearing
ain options configurable, and a separate patch to
> change the defaults.
This patch does not change the defaults, so I'm not sure what you mean here?
--
Vik Fearing
for
settings if we choose to do so because users would be able to switch it
back if they prefer.
The patch is based off of a995b371ae.
--
Vik Fearing
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index a2694e548a..ca2769b02a 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml
orting SCRAM AND every version of PostgreSQL
> supporting SCRAM.
Wasn't SCRAM introduced in 10?
--
Vik Fearing
On 5/22/20 11:24 AM, Peter Eisentraut wrote:
> On 2020-05-20 21:28, Vik Fearing wrote:
>> 1)
>> There are some smart quotes in the comments that should be converted to
>> single quotes.
>
> ok, fixing that
>
>> 2)
>> This query is an infinite
On 5/20/20 3:04 PM, Vik Fearing wrote:
> I'm looking forward to reviewing this.
A few quick things I've noticed so far:
1)
There are some smart quotes in the comments that should be converted to
single quotes.
2)
This query is an infinite loop, as expected:
with recursive a as (selec
inly in the rewriter.
I've attempted to do this several times but didn't get anywhere with it.
I'm looking forward to reviewing this.
(And maybe it will put me on the right path for implementing .)
--
Vik Fearing
e who doesn't want to
rewrite their query to use factorial() instead?
I'm -1 on keeping ! around as a hard-coded postfix operator.
[*] I don't have a concrete example in mind, just this abstract one.
--
Vik Fearing
there was a delay, but it also doesn't bother me.
--
Vik Fearing
cation
> notices published in v13 not v14.
+1
--
Vik Fearing
On 5/18/20 7:03 PM, Alvaro Herrera wrote:
> On 2020-May-18, Vik Fearing wrote:
>
>> The syntax for FETCH FIRST allows the to be
>> absent (implying 1).
>>
>> We implement this correctly for ONLY, but WITH TIES didn't get the memo.
>
> Oops, yes. I
ases for
> factorial are currently in int4.sql, but all the factorial functionality
> was moved to numeric a long time ago.)
>
> What are the thoughts about then marking the postfix operator deprecated
> and eventually removing it?
I am greatly in favor of removing postfix operators as soon as possible.
--
Vik Fearing
The syntax for FETCH FIRST allows the to be
absent (implying 1).
We implement this correctly for ONLY, but WITH TIES didn't get the memo.
Patch attached.
--
Vik Fearing
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 3c78f2d1b5..a24b30f06f 100644
--- a/src/backend
I vote strongly against it.
--
Vik Fearing
On 4/1/20 5:01 AM, Bruce Momjian wrote:
>
> Patch applied though PG 10, thanks.
Thanks!
--
Vik Fearing
ed 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
pressed an opinion either way yet.)
--
Vik Fearing
d it all looks good to me.
I concur. And it matches my reading of the standard (apart from the
intentional derivation).
--
Vik Fearing
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
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
orce_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
ot;;
> tuple = SearchSysCache1(AMNAME,
> PointerGetDatum(accessMethodName));
> }
Aww, this one is in my list of gotcha trivia questions.
That's not a reason not to remove it, of course.
--
Vik Fearing
need to see a
> rebased and updated patch pretty soon. My recommendation is that we
> move this patch to PG14.
I strongly second that motion.
--
Vik Fearing
On 03/03/2020 19:02, Tom Lane wrote:
> Vik Fearing writes:
>> I have a few questions about setting acl on SQL level.
>> Is it safe to do something like
>> UPDATE pg_class SET relacl = $1 WHERE oid = $2;
>> ?
>
>> I don't think it is because ExecGran
base table.
--
Vik Fearing
On 01/03/2020 13:29, Pavel Stehule wrote:
> so 29. 2. 2020 v 11:34 odesílatel Vik Fearing
> napsal:
>
>> On 29/02/2020 06:43, Pavel Stehule wrote:
>>> Hi
>>>
>>> I would to enhance \g command about variant \gcsv
>>>
>>> proposed co
; Options, notes?
But then we would need \ghtml and \glatex etc. If we want a shortcut
for setting a one-off format, I would go for \gf or something.
\gf csv
\gf html
\gf latex
-1 on \gcsv
--
Vik Fearing
ing it very loudly.
> I also don't think that this scales to the case of subtransaction
> commit/rollback. That should surely act the same, but your patch doesn't
> change it.
How does one commit a subtransaction?
> Lastly, introducing a new client-visible message level seems right out.
> That's a very fundamental protocol break, independently of all else.
Yeah, this seemed like a bad idea to me, too.
--
Vik Fearing
t I think that throwing an
> error is actually less astonishing than *not* throwing one.
>
> So, +1 for the proposal from me.
I started this thread for some discussion and hopefully a documentation
patch. But now I have moved firmly into the +1 camp. COMMIT should
error if it can't commit, and then terminate the (aborted) transaction.
--
Vik Fearing
that I described, to
> add the timestamp fields in the progress reporting view. Thought?
+1 on the idea. No opinion on the implementation.
--
Vik Fearing
On 12/02/2020 00:27, Tom Lane wrote:
> Vik Fearing writes:
>> On 11/02/2020 23:35, Tom Lane wrote:
>>> So I assume you're imagining that that would leave us still in
>>> transaction-aborted state, and the session is basically dead in
>>> the water until the u
On 24/02/2020 18:37, David Fetter wrote:
> If we'd done this from a clean sheet of paper, it would have been the
> right decision. We're not there, and haven't been for decades.
OTOH, it's never too late to do the right thing.
--
Vik Fearing
On 24/02/2020 02:31, Robert Haas wrote:
> I am really struggling to see why this is anything but a bug in the
> JDBC driver.
I can follow your logic for it being a bug in the JDBC driver, but
"anything but"? No, this is (also) an undocumented violation of SQL.
--
Vik Fearing
correct but
> if so seemed strange to a non-native speaker).
These changes look good to me.
--
Vik Fearing
er
> words, do the double quotes around "dog" have no effect?
That is correct.
> That would be a bad thing—and it would limit the usefulness of the
> jsonb_object() function.
Use the long form if you need to mix datatypes.
--
Vik Fearing
meric value and the boolean value are double-quoted—in other
> words, they have been implicitly converted to JSON primitive text values.
They haven't been implicitly converted, you gave an array of varchars.
How should it know that you don't want texts?
> Do you agree that this is a bug?
No.
--
Vik Fearing
>
> Clearly, so done as dcdbb5a.
Thanks!
--
Vik Fearing
On 11/02/2020 23:35, Tom Lane wrote:
> Vik Fearing writes:
>> There is a current discussion off-list about what should happen when a
>> COMMIT is issued for a transaction that cannot be committed for whatever
>> reason. PostgreSQL returns ROLLBACK as command tag b
scanner_yyerror, scan.l:1150
postgres=!# commit;
ROLLBACK
should actually produce something like this:
postgres=!# commit;
ERROR: 40P00: transaction cannot be committed
DETAIL: First error was "42601: syntax error at or near "error""
Is this reading correct?
If so, is t
On 06/02/2020 03:56, Vik Fearing wrote:
> On 06/02/2020 03:38, Michael Paquier wrote:
>> On Wed, Feb 05, 2020 at 10:21:11AM -0500, Tom Lane wrote:
>>> Robert Haas writes:
>>>> I'm not really against this change but, given how long it's been the
>>>>
that I know about o_0
That's not our problem.
--
Vik Fearing
still I am not sure what kind of number is enough to define a
> large consensus. Vik, could you start a new thread on -general?
https://www.postgresql.org/message-id/flat/3d8e809b-fc26-87c5-55ac-616a98d2b0be%40postgresfriends.org
--
Vik Fearing
ok.
>
> Doc build ok.
>
> Works for me.
Thanks for the review!
Would you mind changing the status in the commitfest app?
https://commitfest.postgresql.org/27/2427/
--
Vik Fearing
ld be part of the default prompt. Path attached.
>
> Isn't there examples in the documentation which use the default prompts?
>
> If so, should they be updated accordingly?
Good catch!
I thought about the documentation but not the examples therein.
Updated patch attached.
--
Vik Fea
I cannot ever think of a time when I don't want to know if I'm in a
transaction or not (and what its state is). Every new setup I do, I add
%x to the psql prompt.
I think it should be part of the default prompt. Path attached.
--
Vik Fearing
>From 6118b8b2ab4cfc70525666b8d57eaa351d6c2a3d
opy,
> leaving the original NumericVar with a buf pointing to freed memory.
Thank you for taking the time to look closely at this. This was my
first time dealing with "numeric" so I was bound to make some mistakes.
--
Vik Fearing
deal with the tables separately as needed, but I don't see when
a manual vacuum would want to make this distinction.
--
Vik Fearing
In that case should lcm be "...that is an integral multiple..." since
the numeric version will return numeric?
Other than that, I'm happy with this change.
--
Vik Fearing
int not a smallint.
>>
> I see this has been marked RFC. I'll take it,
Thanks!
> and barring objections,
> I'll start by ripping out the smallint code.
No strong objection.
--
Vik Fearing
t; It seems that PERCENT will be easily implemented on that.
>
> However, isn't there a possibility that we allow FETCH FIRST x PERCENT
> WITH TIES, though I'm not sure what SQL spec tells about that? I
> don't come up right now how to do that using window functions..
PERCENT and WITH TIES can play together, per spec.
--
Vik Fearing
On 13/01/2020 15:19, Tom Lane wrote:
> Krasiyan Andreev writes:
>> I want to propose to you an old patch for Postgres 11, off-site developed
>> by Oliver Ford,
>> but I have permission from him to publish it and to continue it's
>> development,
>> that allow distinct aggregates, like select
and rebased my original patch on top of it. Only
the docs changed in the rebase. The original patch (or its rebase) is
what I am interested in.
--
Vik Fearing
On 05/01/2020 13:50, Vik Fearing wrote:
> Okay, now that I see your tests, I understand why everything is broken.
> You only test FROM-TO and with a really wide interval. There are no
> tests for AS OF and no tests for BETWEEN-AND.
I have started working on some better test case
On 06/01/2020 17:03, Tom Lane wrote:
> So it's not clear to me whether we have any meeting of the minds
> on wanting this patch. In the meantime, though, the cfbot
> reports that the patch breaks the ssl tests. Why is that?
I have no idea. I cannot reproduce the failure locally.
201 - 300 of 425 matches
Mail list logo
