From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Philippe BEAUDOIN <phb07(at)apra(dot)asso(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: proposal: schema variables |
Date: | 2020-01-26 17:26:16 |
Message-ID: | CAFj8pRDxHCt9_fDQ8cu07jB4KzyU1qmzgH9uA1XsPdqvZN-w6A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
>
>
> 12) I find it rather suspicious that we make decisions in utility.c
> solely based on commandType (whether it's CMD_UTILITY or not). IMO
> it's pretty strange/ugly that T_LetStmt can be both CMD_UTILITY and
> CMD_PLAN_UTILITY:
>
> case T_LetStmt:
> {
> if (pstmt->commandType == CMD_UTILITY)
> doLetStmtReset(pstmt);
> else
> {
> Assert(pstmt->commandType == CMD_PLAN_UTILITY);
> doLetStmtEval(pstmt, params, queryEnv, queryString);
> }
>
> if (completionTag)
> strcpy(completionTag, "LET");
> }
> break;
>
>
>
It looks strange, but it has sense, because the LET stmt supports reset to
default value.
I can write
1. LET var = DEFAULT;
2. LET var = (query);
In first case I have not any query, that I can assign, and in this case the
LET statement is really only UTILITY.
I did comment there
Regards
Pavel
>
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
Attachment | Content-Type | Size |
---|---|---|
0001-schema-variables-20200126.patch.gz | application/gzip | 64.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2020-01-26 18:48:04 | Re: Add %x to PROMPT1 and PROMPT2 |
Previous Message | Justin Pryzby | 2020-01-26 17:17:37 | Re: explain HashAggregate to report bucket and memory stats |
From | Date | Subject | |
---|---|---|---|
Next Message | Kemal Ortanca | 2020-01-27 13:15:59 | Query optimization advice for beginners |
Previous Message | Pavel Stehule | 2020-01-24 05:08:45 | Re: proposal: schema variables |