Re: proposal: schema variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: schema variables
Date
Msg-id CAFj8pRDxHCt9_fDQ8cu07jB4KzyU1qmzgH9uA1XsPdqvZN-w6A@mail.gmail.com
Whole thread Raw
In response to Re: proposal: schema variables  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: proposal: schema variables  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers



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

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: explain HashAggregate to report bucket and memory stats
Next
From: Fabien COELHO
Date:
Subject: Re: Add %x to PROMPT1 and PROMPT2