On 20/05/18 01:41, Tom Lane wrote:
> Vik Fearing <vik.fear...@2ndquadrant.com> 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 stan
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 TABLE bar
gt; great, but 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
(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 enough with permission checking, but I'm open
to more debate on it.
--
Vik Fearing
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 <vik.fear...@2ndquadrant.com> 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 comi
On 03/04/2018 08:06 PM, Tom Lane wrote:
> Edmund Horner <ejr...@gmail.com> writes:
>> On 26 January 2018 at 13:44, Vik Fearing <vik.fear...@2ndquadrant.com> wrote:
>>> On 01/26/2018 01:28 AM, Edmund Horner wrote:
>>>> The patch mentioned attempts to put
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.
&
hey 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 always use long versions of options whe
On 01/26/2018 01:28 AM, Edmund Horner wrote:
> On 19 January 2018 at 05:37, Vik Fearing <vik.fear...@2ndquadrant.com> wrote:
>> On 01/18/2018 01:07 AM, Tom Lane wrote:
>>> Edmund Horner <ejr...@gmail.com> writes:
>>>> On 15 January 2018 at 15:45, Andres Fr
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 15 36
On Tue, Jan 23, 2018 at 4:17 AM, Edmund Horner <ejr...@gmail.com> 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 Fe
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 completion is missing this trick but that's a different
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.
--
Vik Fear
at all;
> maybe not enough to 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
ch 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
n-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
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 it is correct that t
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 Fearing
On 01/03/2018 08:39 PM, Tom Lane wrote:
> Vik Fearing <vik.fear...@2ndquadrant.com> 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.
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
thought "I could do that!", 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
lp 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 - 425 of 425 matches
Mail list logo
