On Wed, May 29, 2019 at 5:52 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Hm ... I'm not exactly clear on why that would be a superior solution. > It would imply that standalone CREATE INDEX etc would call into the > ALTER TABLE framework --- how is that not equally a layering violation?
Well, the framework could be renamed to something more general, I suppose, but I don't see a *layering* concern. >From my point of view, the DDL code doesn't do a great job separating parsing/parse analysis from optimization/execution. The ALTER TABLE stuff is actually pretty good in this regard. But when you build something that is basically a parse tree and pass it to some other function that thinks that parse tree may well be coming straight from the user, you are not doing a good job distinguishing between a statement and an action which that statement may caused to be performed. > Also, recursive ProcessUtility cases exist independently of this issue, > in particular in CreateSchemaCommand. My worry about my patch upthread > is not really that it introduces another one, but that it doesn't do > anything towards providing a uniform framework/notation for all these > cases. I'm not really sure I understand this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
