On June 5, 2018 9:47 PM, Paul A Jungwirth p...@illuminatedcomputing.com wrote:
> On Sat, May 26, 2018 at 1:56 PM, Vik Fearing vik.fear...@protonmail.com wrote:
>
>> SQL:2011 introduced the concept of a "period". It takes two existing columns
>> and basically does the s
ituation,
> it's enough that we throw a sane error like "ERROR: no snapshot
> available".
>
> Yes, it is incorrect mark. Unfortunately - this is often workaround for
> wrong estimations - so I afraid, in this case, your proposed fix breaks
> lot o
The tab completion for the TABLE command includes indexes but that's a
bug. Attached is a trivial patch to fix it.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff --git a/src/bin/psq
SQL:2011 introduced the concept of a "period". It takes two existing columns
and basically does the same thing as our range types except there is no new
storage. I believe if Jeff Davis had given us range types a few years later
than he did, it would have been using periods.
Attached is a WIP
learly showing it not to be the
> same. 42 vs 43.
>
> Did I misunderstand you?
I think Tom was wondering why it isn't showing 5032703.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
makeSimpleA_Expr(AEXPR_OP, "+",
> NULL, $2, @1); }
> + | '-' I_or_F_const
> + { $$ = doNegate($2, @1); }
I think there should be a comment for why you're accepting FCONST when
the value has to be integral.
--
Vik F
On 20/05/18 01:41, Tom Lane wrote:
> Vik Fearing writes:
>> On 20/05/18 00:57, Tom Lane wrote:
>> I'm +1 for backpatching it. It may be operating as designed by PeterE
>> ten years ago, but it's not operating as designed by the SQL standard.
>
> By that arg
On 20/05/18 01:27, Vik Fearing wrote:
>> Also, why'd you back off "must write" to "should write" in the docs?
>> This doesn't make the parens any more optional than before.
>> It certainly does. It allows this now:
>
> PREPARE foo AS TABL
t it seems more like a feature addition than a bug fix.
>
> I'd be fine with sneaking this into v11, though.
I'm +1 for backpatching it. It may be operating as designed by PeterE
ten years ago, but it's not operating as designed by the SQL standard.
--
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 03/05/2018 11:21 AM, Edmund Horner wrote:
> I am still just slightly unclear on where we are in relation to the
> SAVEPOINT patch -- is that redundant now?
My vote is to reject that patch.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadr
On 03/05/2018 11:33 AM, Edmund Horner wrote:
> On 5 March 2018 at 21:46, Vik Fearing wrote:
>> Tab completion on functions in SELECT (a subset of this thread's patch)
>> is quite important to me personally. I will work on this in the coming
>> days.
>
> It's
On 03/04/2018 08:06 PM, Tom Lane wrote:
> Edmund Horner writes:
>> On 26 January 2018 at 13:44, Vik Fearing wrote:
>>> On 01/26/2018 01:28 AM, Edmund Horner wrote:
>>>> The patch mentioned attempts to put savepoints around the tab
>>>> completion query
params (per queryid).
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 01/27/2018 05:39 PM, David Fetter wrote:
> On Fri, Jan 26, 2018 at 04:28:24PM +0100, Vik Fearing wrote:
>> On 01/26/2018 03:49 PM, David Fetter wrote:
>>> I propose that we do what at least MySQL, Oracle, and DB2 do and
>>> implement DESCRIBE as its own command.
>
On 01/26/2018 03:49 PM, David Fetter wrote:
> I propose that we do what at least MySQL, Oracle, and DB2 do and
> implement DESCRIBE as its own command.
Hard pass.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, For
user is
interested in the short forms, they can issue a \? like everybody else.
> In additional to aiding tab completion discovery of the commands (i.e.
> typing "\desc" and then hitting tab, it would also make scripts a little
> more self-documenting.
I
On 01/26/2018 01:28 AM, Edmund Horner wrote:
> On 19 January 2018 at 05:37, Vik Fearing wrote:
>> On 01/18/2018 01:07 AM, Tom Lane wrote:
>>> Edmund Horner writes:
>>>> On 15 January 2018 at 15:45, Andres Freund wrote:
>>>>> All worries like
;
test'# quit
Use \q to quit or press control-C to clear the input buffer.
test'# \q
test'#
Surely that's not helpful.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
While reviewing the patch for tab completion after SELECT, I realized
that psql doesn't know how to complete after FROM if the ONLY keyword is
present.
This trivial patch fixes that, as well as JOIN ONLY and TABLE ONLY.
--
Vik Fearing +33 6 46 75
On Tue, Jan 23, 2018 at 4:17 AM, Edmund Horner wrote:
> Hi Vik, thanks for the feedback!
>
Don't forget to include the list :-)
I'm quoting the entirety of the message---which I would normally trim---for
the archives.
> On 23 January 2018 at 07:41, Vik Fearing
> wrote:
Matches1, you miss cases like
this: SELECT (SELECT
It also occurred to me that SELECT isn't actually a complete command (or
whatever you want to call it), it's an abbreviation for SELECT ALL. So
you should check for SELECT, SELECT ALL, and SELECT DISTINCT. (The FROM
tab comple
On 01/12/2018 06:59 AM, Edmund Horner wrote:
> Hi, here's a new patch.
Thanks, and sorry for the delay. I have reviewed this patch, but
haven't had time to put my thoughts together in a coherent message yet.
I will be able to do that tomorrow.
Thank you for your patience.
--
o tip the scales against it, but still a demerit.
I don't really want such a patch. I use new psql on old servers all the
time.
--
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
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
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
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
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
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
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
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
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
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
be.
This patch is based off of 5303ffe71b.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff --git a/contrib/pg_stat_statements/Makefile b/contrib/pg_stat_statements/Makefile
index 39b368b70e
list to help me understand tuple
descriptors better.
Ready for committer.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
401 - 436 of 436 matches
Mail list logo
