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
A_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 Fearing
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
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
t the output I pasted was clearly 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
this is a bugfix or an improvement. I'm leaning
towards bugfix.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index f4133953be
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
that situation,
> 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 of app
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
On 29/06/18 10:14, Sergei Kornilov wrote:
> It may be better to use NULL as the default value at sql level.
Absolutely. +1 from me.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
I prefer the former.
> + use instead. Although PostgreSQL won't
> prevent you
> + from doing so, but beware that dumps generated by
> pg_dump
No but.
> + or pg_dumpall may be hard
> + to restore because of such checks, as the underlying dependencies are
>
On 26/06/18 09:49, Lætitia Avrot wrote:
> Thanks a lot. I did the modification. It's in the patch enclosed.
Looks good to me.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
supported asciidoc
>> since PG 9.5.
>
> I would welcome markdown output, particularly some version that can be
> processed nicely by pandoc :-)
I use latex format for that, but I also welcome a markdown format.
--
Vik Fearing +33 6 46
some wordsmithing throughout. It does not deal with the
other issues I raised.
Marked "Waiting on Author".
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff --git a/doc/src/sgml/config.
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
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
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
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
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/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
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 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
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
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.
&
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
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 <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.
ut I doubt that'd really be worth the trouble.
If someone were to waste their time doing it, would we want FUNCTION or
ROUTINE?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
t would be here.
That would just mean that query_start would be older than xact_start,
but that's okay because the displayed query would be a CALL so we'll
know what's going on.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
lize equality is a special case of discrete,
> but having such cases be marked as UNIQUE seems too confusing.
One of the things I'm currently trying to implement is the WITHOUT
OVERLAPS for UNIQUE constraints.
See SQL:2016 section 11.7
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
s view.
Yes, I think that was a very bad idea.
> What do you think of : log_min_duration_statement_sample ?
Hmm. Not sure if that last word should be _sample, _sampling, _rate, or
a combination of those.
> Is it too long?
I introduced idle_in_transaction_session_timeout, so I'm not one to say
a setting name is too long :)
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 11/07/18 11:04, Yugo Nagata wrote:
> A usecase I suppose is that when a new expression index is created and that
> we need only the statistics for the new index.
I wonder if this shouldn't just be done automatically.
--
Vik Fearing +33 6 46 75
On 24/07/18 22:50, Andrew Gierth wrote:
> Haven't had time yet to poke at what's changed in detail.
git bisect lays the blame on 6719b238e8f0ea83c39d2b1728c7670cdaa34e06.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expert
few versions
before it's removed completely.
-1 on this patch
+1 for removing the "feature"
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
is the rational?
It's first on our list of things not to do:
https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_psql_-W_or_--password
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
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
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
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
(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/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 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/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
that's both inefficient
Hmm, converting it back is exactly what my function does...
> and mighty confusing.
This is my justification for needing the patch.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 29/10/2018 16:26, Andreas Karlsson wrote:
> On 10/29/2018 04:18 PM, Vik Fearing wrote:
>> A use case that I see quite a lot of is needing to do reports and other
>> calculations on data per day/hour/etc but in the user's time zone. The
>> way to do that is fairly trivial,
to create a function for it, based off 5953c99697.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96d45419e5..304fa638fe 100644
--- a/doc
On 29/10/2018 17:12, Steve Crawford wrote:
> On Mon, Oct 29, 2018 at 8:44 AM Vik Fearing <mailto:vik.fear...@2ndquadrant.com>> wrote:
>
> On 29/10/2018 16:26, Andreas Karlsson wrote:
> > On 10/29/2018 04:18 PM, Vik Fearing wrote:
> >> A use case tha
hed patch add this possibility to least, greatest functions.
Is there any particular reason you didn't just make least and greatest
actual functions?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 14/11/2018 21:42, Tom Lane wrote:
> I wrote:
>> Here's a v2 that transposes the code to C so that we can get that
>> optimization.
>
> Pushed after a bit more testing and documentation-wordsmithing.
Thank you, Tom!
--
Vik Fearing
On 30/09/18 05:48, Andres Freund wrote:
> 5a) The fact that system table oids don't show up in selects by default
>makes it more work than necessary to look at catalogs.
As a user, this is a big pain point for me. +1 for getting rid of it.
--
Vik F
to fix it, but it's so ridiculously
small that I fear I'm missing something.
I don't think this needs any documentation and I didn't see where we
have any existing tests for eval_const_expressions so I didn't create
any either.
Thoughts?
--
Vik Fearing +33
I don't understand why that's the case but there's a
regression test specifically for it so I never did anything about it.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
same
> reasons. So there doesn't in this case seem to be any reason to keep
> them around until the transaction's fate is known.
Isn't that what happens already? PrepareTransaction() calls
PreCommit_on_commit_actions() from what I can tell.
--
Vik Fearing
is to have homogeneous syntax for all of this, and so put it in
parentheses, but we should also allow CREATE INDEX and DROP INDEX to use
parentheses for it, too.
I supposed we'll keep what would then be the legacy syntax for a few
decades or more.
--
Vik Fearing +33 6 46
On 19/01/2019 02:33, Michael Paquier wrote:
> On Fri, Jan 18, 2019 at 07:58:06PM +0100, Vik Fearing wrote:
>> My vote is to have homogeneous syntax for all of this, and so put it in
>> parentheses, but we should also allow CREATE INDEX and DROP INDEX to use
>> pa
it in the code is:
>
> /* we ignore rowMarks */
>
> I propose that it should not ignore rowMarks, per the attached patch or
> something similar.
>
> (thanks to Vik Fearing for preliminary testing)
I don't this needs any documentation changes, but some tests would be
nice. I will g
On 19/01/2019 18:02, Tom Lane wrote:
> Vik Fearing writes:
>> Does the extension need a version bump for this?
>
> We don't bump its version when we make any other change that affects
> its hash calculation. I don't think this could be back-patched,
> but Andrew wasn't pro
o ask you
> So now, I think we need to ask that fundamental question :
>
> ***Is it worth it ?***
And my answer to that is:
No. Markdown isn't standardized enough to support and please everyone.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant
On 30/11/2018 21:15, Andres Freund wrote:
> Secondarily, csvlog doesn't contain all the interesting information.
It doesn't? What is it missing?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Andrew Gierth's approach. I would rather see something like that.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 25/11/2018 12:49, Surafel Temesgen wrote:
>
>
> On Sun, Nov 25, 2018 at 1:24 PM Vik Fearing <mailto:vik.fear...@2ndquadrant.com>> wrote:
>
>
> Also, this query returns 210 rows instead of the expected 208:
>
> select *
> from gene
lies to
>>> statement logging. I'd say log_statement_sample_rate is better.
>>
>> I agree, sounds reasonable.
>>
>
> Thanks for your comments. Here is the updated patch. I fixed a warning for
> missing parentheses in this expression:
> if ((exceeded && in_sa
On 27/11/2018 01:10, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 27/11/2018 01:05, Stephen Frost wrote:
>>> That said, I do *not* think we should make any assumptions here- users
>>> incorrectly mark things all th
On 27/11/2018 01:14, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 27/11/2018 01:10, Stephen Frost wrote:
>>> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>>>> On 27/11/2018 01:05, Stephen Frost wrote:
immutable
function is not parallel safe.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
signature.asc
Description: OpenPGP digital signature
mean we also shouldn't assume that functions marked as
immutable are index safe?
User error is user error.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
signature.asc
Description: OpenPGP digital signature
On 27/11/2018 01:40, Tom Lane wrote:
> Vik Fearing writes:
>> On 27/11/2018 01:13, Stephen Frost wrote:
>>> Parallel safe functions should be marked as such. Immutable functions
>>> should be marked as such. We should not assume that one implies the
>&
; select pg_stat_statements_reset(NULL,NULL,NULL);
> -- No change, just return. Because the function is strict.
>
> select pg_stat_statements_reset(0,0,0);
> -- Resets all the statements
>
> select pg_stat_statements_reset(0,10,0);
> -- Resets all the statements executed on databa
function not
parallel safe?
Sure it could be mislabeled as immutable but it could just as easily be
mislabeled as parallel safe. And we already treat fake immutable
functions as user errors, for example in indexes.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQu
On 27/11/2018 00:39, Andres Freund wrote:
> Hi,
>
> On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
>> On 26/11/2018 22:23, Gajus Kuizinas wrote:
>>> I was wondering what is the reason IMMUTABLE functions are not by
>>> default PARALLEL SAFE and if the d
do crash recovery before entering archive
> recovery, but nothing else.)
Bump.
I was the originator of this report. I work with Postgres every single
day and I was spooked by these warnings. People with much less
involvement would probably be terrified.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
s good to me.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
s, please add it to the next commitfest.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 30/12/2018 19:44, Tom Lane wrote:
> Vik Fearing writes:
>> On 30/12/2018 00:36, Tom Lane wrote:
>>> Can we assume that the underlying datatype comparison function is
>>> immutable? I guess so, since we assume that in nearby code such as
>>> contain_mutable
NALYZE 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
; Yeah, I thought about that too, but it doesn't seem like an improvement.
> If the query is very long (which isn't unlikely) I think people would
> prefer to see the option(s) up front.
On the other hand, the end is where the other options go (that we
haven't implemented yet). See .
--
Vik
_reset() causes an immediate autovacuum for all tables, so maybe
> it's not quite that simple.
Not just pg_stat_reset() but also on promotion.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 23/06/2019 12:35, Thomas Munro wrote:
> On Sun, Jun 23, 2019 at 9:21 PM Vik Fearing
> wrote:
>> There is some language in a code comment that has been bothering me for
>> several years now. After pointing it out in a conversation off-list
>> recently, I figure
There is some language in a code comment that has been bothering me for
several years now. After pointing it out in a conversation off-list
recently, I figured it was past time to do something about it.
Patch attached.
--
Vik Fearing +33 6 46 75 15 36
that the user might have been trying to use a window function.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff --git a/src/backend/parser/parse_agg.c b/src/backend/parser/parse_agg.c
index c745fcdd2
plain_format.
Of course if you default BUFFERS to on(*) and don't do ANALYZE, that
should not result in an error.
(*) Defaulting BUFFERS to on is something I want regardless of anything
else we do.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr
just once per row rather than each time like the first query.
Is this as designed? It's certainly unexpected, and my initial reaction
is undesirable.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Thursday, July 4, 2019 8:04 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
> Hello Vik,
> On 2018-Jun-05, Vik Fearing wrote:
>
>>> I understand that your patch is just to allow defining periods, but I
>>> thought I'd share my own hopes earlier rather than later
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
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%'::
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 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 BY DEF
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 downgrading and
On 30/10/2019 09:04, Fabien COELHO wrote:
>
>> I think possibly what the spec says (and that neither my patch nor
>> Peter's implements) is assigning the alias just to the > list>.
>
> I think you are right, the alias is only on the identical columns.
>
> It solves the issue I raised about
t;> I'll send a patch.
> If we do this, cluster_name should be included in csvlog?
Yes, absolutely.
--
Vik Fearing
On 05/11/2019 02:45, Alexander Korotkov wrote:
> 3) Do we like to change behavior to_date()/to_timestamp()? Or just
> jsonpath .datetime() and future CAST(... AS ... FORMAT ...) defined in
> SQL 2016?
I don't want to hijack this thread, but I would like the CAST feature to
call to_timestamp()
On 28/10/2019 13:48, Surafel Temesgen wrote:
>
>
> On Fri, Oct 25, 2019 at 10:45 PM Vik Fearing
> mailto:vik.fear...@2ndquadrant.com>> wrote:
>
> >
> > I don't understand what you mean by this.
> >
> >
> >
> >
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 s
for this by allowing an alias on
the join clause. ( in section 7.10)
SELECT j.x, j.y, j.z FROM a INNER JOIN b USING (z) AS j;
Attached is a patch (based on 517bf2d910) adding this feature.
--
Vik Fearing
diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
index 22252556be
On 29/10/2019 12:24, Isaac Morland wrote:
> If you need to refer specifically to the non-qualified version in a
> different part of the query, you can give an alias to the result of
> the join:
>
> ... (a join b using (z)) as t ...
Yes, this is about having standard SQL syntax for that.
On 29/10/2019 12:05, Peter Eisentraut wrote:
> On 2019-10-29 11:47, Vik Fearing wrote:
>> When joining tables with USING, the listed columns are merged and no
>> longer belong to either the left or the right side. That means they can
>> no longer be qualified which can ofte
On 29/10/2019 15:20, Tom Lane wrote:
> Vik Fearing writes:
>> On 29/10/2019 12:24, Isaac Morland wrote:
>>> If you need to refer specifically to the non-qualified version in a
>>> different part of the query, you can give an alias to the result of
>>> the joi
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!
1 - 100 of 425 matches
Mail list logo
