Tom Lane wrote:
> Fernando Nasser <fnasser(at)redhat(dot)com> writes:
> > I have no problem with that. I will be pleased to make SELECT...INTO
> > generate a CreateAsStmt and it will also print CREATE.
> Well, if you want to do that then there should be actual revisions to
> the parsetree representation (viz, get rid of INTO), so as to make this
> stuff cleaner instead of dirtier. INTO is really quite messy right now,
> since we have to cope with pulling what ought to be a top-level
> construct out of a nested SelectStmt. I would like to see CreateAs
> be a separate statement construct having three fields: target table
> name, optional column name list, and source SelectStmt (pointer to
> a SELECT parsetree). Then we could remove the INTO field from
> SelectStmt and make the parsetree and parse analysis work cleaner.
> However, right now this transformation is (effectively) done in
> analyze.c, and I'm not sure whether it can be done as cleanly in
> gram.y. But do take a look at it ...
OK, I will take a look to see how difficult it would be to get rid
of 'into' by having a full fledge CreateAsStmt.
> The alternative is to stick with the existing parsetree representation
> and just tweak the command-tag-extraction code to look for an into
> clause and print CREATE if so.
Yes, that is a simple solution. If the above is to difficult we can do
that. Thanks for the suggestion.
I will rework the patch to one form or the other.
Red Hat Canada Ltd. E-Mail: fnasser(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
In response to
pgsql-patches by date
|Next:||From: Bruce Momjian||Date: 2002-02-25 16:30:38|
|Subject: Re: Added Encoding|
|Previous:||From: Fernando Nasser||Date: 2002-02-25 14:46:05|
|Subject: Re: [HACKERS] Updated TODO item|