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.
>
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 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
rom 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
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
ut 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
feats inlining.
Patch attached.
--
Vik Fearing
>From 6429316ab6060a16889b7c188ca577e17a5c7e4c Mon Sep 17 00:00:00 2001
From: Vik Fearing
Date: Tue, 16 Feb 2021 18:38:24 +0100
Subject: [PATCH] implement trim_array
---
doc/src/sgml/func.sgml | 19 +++
src/include
On 2/16/21 7:32 PM, Isaac Morland wrote:
> On Tue, 16 Feb 2021 at 12:54, Vik Fearing wrote:
>
>> The SQL standard defines a function called TRIM_ARRAY that surprisingly
>> has syntax that looks like a function! So I implemented it using a thin
>> wrapper around our ar
On 2/16/21 11:38 PM, Vik Fearing wrote:
> On 2/16/21 7:32 PM, Isaac Morland wrote:
>> On Tue, 16 Feb 2021 at 12:54, Vik Fearing wrote:
>>
>>> The SQL standard defines a function called TRIM_ARRAY that surprisingly
>>> has syntax that looks like a function!
On 2/17/21 1:25 AM, Vik Fearing wrote:
> I've made a bit of a mess out of this, but I partly blame the standard
> which is very unclear. It actually describes trimming the right n
> elements instead of the left n like I've done here. I'll be back later
> with a bette
)
expands to the sets:
(a,b,c), (a,b), (a,b), (a,c), (a), (a), (a,c), (a), ()
but:
GROUP BY DISTINCT ROLLUP (a,b), ROLLUP (a,c)
expands to just the sets:
(a,b,c), (a,b), (a,c), (a), ()
Attached is a patch to implement this for PostgreSQL.
--
Vik Fearing
>F
On 2/21/21 3:06 PM, e...@xs4all.nl wrote:
>> On 2021.02.21. 13:52 Vik Fearing wrote:
>>
>> Attached is a patch to implement this for PostgreSQL.
>> []
>
> The changed line that gets stuffed into sql_features is missing a terminal
> value (to fill the 'co
nd I would like for it to appear there.
Please consider.
--
Vik Fearing
>From a06fd975ef14930bbef2dac3597272289d6b10eb Mon Sep 17 00:00:00 2001
From: Vik Fearing
Date: Fri, 13 Nov 2020 11:55:58 +0100
Subject: [PATCH 1/2] Add catalog version to pg_config
---
doc/src/sgml/ref/pg_config
On 2/22/21 12:48 AM, Andres Freund wrote:
> Hi,
>
> On 2021-02-22 00:15:20 +0100, Vik Fearing wrote:
>> I do some very regular testing on HEAD and my scripts need to know if
>> the catalog version has changed to determine if it needs to pg_restore
>> or if a basebacku
like to re-use a "template" data directory with the
> data loaded if possible (i.e. no catversion / WAL / ... version bumps),
> and a pg_upgrade otherwise.
This is exactly what I am doing.
--
Vik Fearing
02x draft.
Yay!
> Here is a patch for it.
This looks good to me, except that you forgot to add the feature stamp.
Attached is a small diff to apply on top of your patch to fix that.
--
Vik Fearing
diff --git a/src/backend/catalog/sql_features.txt b/src/backend/catalog/sql_features.txt
index a2
On 2/22/21 1:28 PM, Peter Eisentraut wrote:
> On 22.02.21 11:05, Vik Fearing wrote:
>> This looks good to me, except that you forgot to add the feature stamp.
>> Attached is a small diff to apply on top of your patch to fix that.
>
> The feature code is from SQL:202x,
us of this patch is: Waiting on Author
I put it back to Needs Review without a new patch because I don't know
what I would change.
--
Vik Fearing
On 3/2/21 1:02 AM, Dian M Fay wrote:
> On Mon Mar 1, 2021 at 6:53 PM EST, Vik Fearing wrote:
>>> This basically does what it says, and the code looks good. The
>>> documentation is out of alphabetical order (trim_array should appear
>>> under cardinality rather
I will be bumping to 'Ready for Committer' unless objections.
In that case, here is another patch that fixes a typo in the docs
mentioned privately to me by Erik. The typo (and a gratuitous rebase)
is the only change to what you just reviewed.
--
Vik Fearing
>From e8c0042267abc2dedea8ecca2c6
On 3/3/21 6:35 PM, Peter Eisentraut wrote:
> On 22.02.21 08:00, Vik Fearing wrote:
>> On 2/22/21 3:24 AM, Andres Freund wrote:
>>> Imagine trying to run regular tests of HEAD, where the tests require a
>>> large database to be loaded. Re-loading the data for
ding
> of the semantics.
Thank you.
> Looks good otherwise, so pushed.
Thanks!
--
Vik Fearing
se, is there some way to refuse to execute
> it if it doesn't contain an unambiguous ORDER BY, as illustrated
> below?
>
> SELECT BIT_XOR(b ORDER BY a, c).../* works */
> SELECT BIT_XOR(b) OVER (ORDER BY a, c)... /* works */
> SELECT BIT_XOR(b) FROM... /* errors out */
Why would such an error be necessary, or even desirable?
--
Vik Fearing
On 3/6/21 9:00 PM, David Fetter wrote:
> On Sat, Mar 06, 2021 at 08:57:46PM +0100, Vik Fearing wrote:
>> On 3/6/21 8:55 PM, David Fetter wrote:
>>> On Wed, Mar 03, 2021 at 03:30:15PM +0100, Peter Eisentraut wrote:
>>>> On 10.02.21 06:42, Kyotaro Horiguchi wrot
;>
>
> Numerous existing aggregate functions have this behavior. Making those
> error isn’t an option. So is making this a special case something we want
> to do (and also maybe make doing so the rule going forward)?
Aside from the fact that bit_xor() does not need this, I am opposed to
it in general. It is not our job to make people write correct queries.
--
Vik Fearing
On 3/7/21 10:53 AM, Pavel Stehule wrote:
> ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing
> napsal:
>
>> On 3/6/21 9:06 PM, David G. Johnston wrote:
>>> On Saturday, March 6, 2021, David Fetter wrote:
>>>
>>>>
>>>>>> SELECT B
On 3/7/21 11:05 AM, Pavel Stehule wrote:
> ne 7. 3. 2021 v 11:02 odesílatel Vik Fearing
> napsal:
>
>> On 3/7/21 10:53 AM, Pavel Stehule wrote:
>>> ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing
>>> napsal:
>>>
>>>> On 3/6/21 9:06 PM, Dav
ntax for median (percentile_cont(0.5)) already requires an order
by clause. You are now requiring one on array_agg().
--
Vik Fearing
On 3/7/21 11:37 AM, Pavel Stehule wrote:
> ne 7. 3. 2021 v 11:28 odesílatel Vik Fearing
> napsal:
>
>> On 3/7/21 11:24 AM, Pavel Stehule wrote:
>>>>
>>>> And so you are now mandating an ORDER BY on every query and in every
>>>> aggregate and/o
ag to get StartTime/EndTime column name,
>>> thought?
>>>
>>>
> For me your option is better. i will change to it in my next
> patch if no objection
I have plenty of objection. I'm sorry that I am taking so long with my
review. I am still working on it and it is coming soon, I promise.
--
Vik Fearing
should be changed to fit in that? I left it
alone for now.
I also snuck in something that all of us overlooked which is outputting
the DISTINCT in ruleutils.c. I didn't add a test for it but that would
have been an unfortunate bug.
New patch attached, rebased on 15639d5e8f.
--
Vik Fearin
at the start of every month (I started late in
October).
[1]
https://www.enterprisedb.com/blog/postgresql-tproc-c-benchmarks-postgresql-12-vs-postgresql-13-performance
--
Vik Fearing
d 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
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
E
vik=# select array_cat(a) from (values (array[1]), (array[2])) as v(a);
array_cat
---
{1,2}
(1 row)
--
Vik Fearing
ve?
create 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
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
to diagnose potential 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
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
ted to share this in case this idea 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
alidity 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
ion for this feature which implements all the
requirements of the standard (except syntax grammar, of course).
https://github.com/xocolatl/periods/
--
Vik Fearing
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 s
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 &
ALTER TABLE 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/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.leadb
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.
>
of 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
make 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
On 1/11/21 3:02 PM, Simon Riggs wrote:
> * UPDATE foo SET start_timestamp = DEFAULT should fail but currently doesn't
I'm still in the weeds of reviewing this patch, but why should this
fail? It should not fail.
--
Vik Fearing
On 1/26/21 1:16 PM, Simon Riggs wrote:
> On Tue, Jan 26, 2021 at 11:33 AM Vik Fearing wrote:
>>
>> On 1/11/21 3:02 PM, Simon Riggs wrote:
>>> * UPDATE foo SET start_timestamp = DEFAULT should fail but currently doesn't
>>
>> I'm still in the weed
AIN should become ROLLBACK AND NO CHAIN.
--
Vik Fearing
On 1/26/21 6:34 PM, Vik Fearing wrote:
> On 1/26/21 6:20 PM, Laurenz Albe wrote:
>> After thinking some more about it, I think that COMMIT AND CHAIN would have
>> to change behavior: if COMMIT throws an error (because the transaction was
>> aborted), no new transact
suitable reserved keyword?
I don't particularly like this whole idea anyway, but if we're going to
have it, I would suggest
JOIN ... USING KEY ...
since USING currently requires a parenthesized list, that shouldn't
create any ambiguity.
> How about JOIN WITH?
WITH is severely overloaded already.
--
Vik Fearing
Surafel's attempt because it was
confusing the period with SYSTEM VERSIONING. Versioning needs the
period but the inverse is not true.
--
Vik Fearing
When table oids were removed by commit 578b229718e, the function
CatalogTupleInsert() was modified to return void but its comment was
left intact. Here is a trivial patch to fix that.
--
Vik Fearing
diff --git a/src/backend/catalog/indexing.c b/src/backend/catalog/indexing.c
index 284ceaa6b9
On 3/17/21 9:11 AM, Michael Paquier wrote:
> On Wed, Mar 17, 2021 at 08:31:16AM +0100, Vik Fearing wrote:
>> When table oids were removed by commit 578b229718e, the function
>> CatalogTupleInsert() was modified to return void but its comment was
>> left intact. Here is a triv
d.
>
> So, my question is: what do you think about such a feature? is it worth it?
Yes, it is absolutely worth it to be able to extract just the functions
from a database. I have wanted this several times.
--
Vik Fearing
On 3/17/21 3:48 PM, Tom Lane wrote:
> Also, the SQL spec says in so many words
> that the SQL-defined datetime types follow the Gregorian calendar.
We already don't follow the SQL spec for timestamps (and I, for one,
think we are better for it) so I don't think we should worry abo
again until I finish my review of
the system versioning patch.
> perhaps it would be better to close it as Returned with
> Feedback for now and reopen it when you have a new patch?
If that is preferred over moving it to PG15, then no objection. As long
as people don't think I've abandoned it.
--
Vik Fearing
ompilers noticed
> this, not the new fancy ones.
+1
I'm glad the buildfarm is so diverse.
--
Vik Fearing
ished, I would like to see
this integrated into the tree, perhaps even directly into psql itself
(unless the user chooses a different pager). It is that useful.
Thank you, Pavel, for this work.
--
Vik Fearing
L standard. The timeline on
that website says August 2022 (it started in September 2019).
If that timeline holds and ambitious people work on it (I already know
one who is; not me), I would expect this to be in PostgreSQL 16 or 17.
The earliest your proposal could get in is 15, so it's not that much of
a wait.
--
Vik Fearing
On 3/28/21 1:26 PM, Joel Jacobson wrote:
> On Sun, Mar 28, 2021, at 12:25, Vik Fearing wrote:
>> On 3/27/21 9:27 PM, Joel Jacobson wrote:
>>> Imagine if we could simply write the SQL query like this:
>>>
>>> SELECT DISTINCT od.order_id.customer_id.compa
CREATE TABLE products OF products (
REF IS product_id SYSTEM GENERATED
);
CREATE TABLE order_details (
"order" REF(orders),
product REF(products),
quantity integer,
PRIMARY KEY ("order", product)
);
And the query would be:
SELECT DISTINCT order_details."order"->customer->company_name
FROM order_details
WHERE order_details.product->product_name = 'Chocolade';
Postgres already supports most of that, but not all of it.
--
Vik Fearing
On 3/29/21 7:55 PM, Joel Jacobson wrote:
> On Mon, Mar 29, 2021, at 16:17, Vik Fearing wrote:
>> CREATE TABLE order_details (
>> "order" REF(orders),
>> product REF(products),
>> quantity integer,
>> PRIMARY KEY ("order", product
ld joins and modern joins, and you
> are inventing a third syntax.
I'm with you on this: let's do it the Standard way, or not do it at all.
--
Vik Fearing
> "break" these cases anyway. Better to be clear that such nonsense isn't
> intended to be accepted and clean that up. I do think it'd be good to
> accept the current database name there as that's reasonable.
I am going to throw my hat in with Robert and Stephen, too. At least
for 15 if we don't want to change this behavior in back branches.
--
Vik Fearing
On 10/13/21 2:06 AM, Bossart, Nathan wrote:
> On 10/11/21, 11:03 AM, "Vik Fearing" wrote:
>> On 10/11/21 5:25 PM, PG Bug reporting form wrote:
>>>
>>> User 'musttu' on IRC reported the following bug: After running "ALTER INDEX
>>> so
d want to see ALL columns.
I disagree strongly with this. It is really annoying when working
interactively with psql on a table that has a PostGIS geometry column,
or any other large blobby type column.
I have not looked at the patch, but +1 for the feature.
--
Vik Fearing
On 10/17/21 11:01 PM, Gilles Darold wrote:
>
> - Add a check into SET UNEXPANDED code to verify that there is at
> least one column expanded.
What is the point of this? Postgres allows column-less tables.
Both of these statements are valid:
- CREATE TABLE nada ();
- SELECT
27;t think of an interest to allow that.
Allowing no-column tables removed the need to handle a bunch of corner
cases. Useful for users or not, the precedent is set.
--
Vik Fearing
)?
If we're going to do something like that, we should convert it from a
boolean to an enum.
log_checkpoints = wal
(I'm being very careful not to slip on that slope.)
--
Vik Fearing
is?
GRANT VACUUM, ANALYZE ON TABLE foo TO bar;
That doesn't fix the CHECKPOINT issue, but surely vacuum and analyze can
be done that way. I would much prefer that over new predefined roles.
This would be nice, but there is nothing to hang our hat on:
GRANT CHECKPOINT TO username;
--
Vik Fearing
On 11/2/21 11:14 PM, Vik Fearing wrote:
> This would be nice, but there is nothing to hang our hat on:
>
> GRANT CHECKPOINT TO username;
Thinking about this more, why don't we just add CHECKPOINT and
NOCHECKPOINT attributes to roles?
ALTER ROLE username WITH CHECKPOINT;
--
Vik Fearing
required(and
> it should not error-out by Postgres).
What could possibly be the use case for this?
> Thoughts?
I don't like it.
--
Vik Fearing
PLAIN).
The patch looks good to me, too.
+1
--
Vik Fearing
d just be rejected, unfortunately.
The design decisions are just too flawed, and it conflates system_time
periods with system versioning which is very wrong.
--
Vik Fearing
k
> (susperuser/role_read_all_stats). Unfortunately we can't use the same
> approach as pg_stat_activity (only showing data for user's own queries).
> Well, we could keep per-user samples, but that might considerably
> inflate the file size.
I think I handle that well enoug
On 23/10/2019 17:56, Surafel Temesgen wrote:
>
> Hi all ,
>
> Temporal table is one of the main new features added in sql standard
> 2011. From that I will like to implement system versioned temporal
> table which allows to keep past and present data so old data can be
> queried.
>
Excellent! I'v
On 24/10/2019 16:54, Surafel Temesgen wrote:
>
> hi Vik,
> On Wed, Oct 23, 2019 at 9:02 PM Vik Fearing
> mailto:vik.fear...@2ndquadrant.com>> wrote:
>
>
>
> If we're going to be implicitly adding stuff to the PK, we also
> need to
> add that
On 25/10/2019 11:56, Surafel Temesgen wrote:
>
>
> On Thu, Oct 24, 2019 at 6:49 PM Vik Fearing
> mailto:vik.fear...@2ndquadrant.com>> wrote:
>
> On 24/10/2019 16:54, Surafel Temesgen wrote:
> >
> > hi Vik,
> > O
On 26/10/2019 17:41, Eugen Konkov wrote:
> Hi.
>
> I have noticed that it would be cool to use '==' in place of 'IS NOT
> DISTICT FROM'
>
> What do you think about this crazy idea?
I think this is a terrible idea. The only reason to do this would be to
index it, but indexes (btree at least) ex
YZE does.
> It's my first patch on Postgres, it's probably all wrong but I hope it
> helps you get the idea.
This was suggested and rejected years ago:
https://www.postgresql.org/message-id/b970f20f-f096-2d3a-6c6d-ee887bd30...@2ndquadrant.fr
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 18/08/2019 11:03, Peter Eisentraut wrote:
>
> a UNION b
>
> vs
>
> a UNION CORRESPONDING b
I have a WIP patch for CORRESPONDING [BY]. Is there any interest in me
continuing it? If so, I'll start another thread for it.
--
Vik Fearing
Is there a reason why the serial pseudotypes still behave as they did
pre-v10 and don't map to GENERATED BY DEFAULT AS IDENTITY these days?
I'm hoping it's just an oversight and I can help "fix" it, but maybe
there is an actual reason for it to be this way?
--
Vik Fearing
On 25/08/2019 18:59, Tom Lane wrote:
> Vik Fearing writes:
>> Is there a reason why the serial pseudotypes still behave as they did
>> pre-v10 and don't map to GENERATED BY DEFAULT AS IDENTITY these days?
> Backwards compatibility?
With what? We don't support downg
On 25/08/2019 19:42, Tom Lane wrote:
> Vik Fearing writes:
>> On 25/08/2019 18:59, Tom Lane wrote:
>>> Vik Fearing writes:
>>>> Is there a reason why the serial pseudotypes still behave as they did
>>>> pre-v10 and don't map to GENERATED B
hat direction than the current one.
I am not advocating we attempt anything more complex such as "x ~>=~ 'y'
AND x ~<~ 'z'", just that we output SQL where feasible. I would like to
fiddle with this if there is consensus that a decent patch would be
accepted.
--
Vik Fearing
On 25/08/2019 21:14, Tom Lane wrote:
> Vik Fearing writes:
>> EXPLAIN (COSTS OFF) SELECT * FROM pg_am WHERE amname LIKE '%t%';
>> QUERY PLAN
>> ---
>> Seq Scan on pg_am
>> Filter: (amname
t!", so I did. I got lucky
> and it was accepted, but without that list, I'd probably never have
> written the patch and probably not be here today.
I, too, came in through the TODO list.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
next cab off the rank in the
> SQL/JSON work.
>
>
> It seems like something worth having quite independently of the SQL/JSON
> stuff anyway.
Shouldn't this support TZS or something for seconds?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 01/03/2018 08:39 PM, Tom Lane wrote:
> Vik Fearing writes:
>> Shouldn't this support TZS or something for seconds?
>
> According to the docs I cited upthread, there's no such field type
> in Oracle.
So what?
--
Vik Fearing
On 01/04/2018 07:32 AM, Fabien COELHO wrote:
>
> Another rebase to try to please the patch tester.
Thank you. I plan on reviewing this over the weekend.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Format
at's
> your prerogative.
>
> Can we find somebody else willing to implement the agreed-upon behavior?
I'm currently reviewing two other patches in the commitfest (in my
limited time). When I'm done with those I would be happy to pick this
up if no one else has.
--
Vik F
ving things around.
> TAP tests ensure reasonable coverage of the feature.
And the documentation seems sufficient, as well.
It's a shame this feature uses \elif instead of \elsif to be closer to
plpgsql, but I suppose this ship already sailed when psql chose \elif,
and I think
a later patch. I'd rather have what
you've got now than nothing at all.
> - How do we make it work with older servers, e.g. those that predate
> some of the newer columns used in the function criteria?
This is something that's going to have to be addressed if this patc
s distinctly non-PostgreSQL-esque.
I'm -1 on such a patch, even though I would really like this feature.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
proffer the column/function completions.
>
> There may be other completions that could benefit from such a check,
> e.g. table names after a comma in the FROM clause, but I just want to
> get SELECT working first.
I would like to see this as a separate patch. Let's keep this one
simple and just do like the other things currently do.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 01/13/2018 10:52 PM, Stephen Frost wrote:
> Vik, all,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 01/09/2018 02:29 AM, Alvaro Herrera wrote:
>>> Everaldo Canuto wrote:
>>>> Change my patch will make psql different from other sql c
1 - 100 of 446 matches
Mail list logo
