On Tue, Aug 04, 2009 at 10:55:07PM -0400, Tom Lane wrote:
> Dan Colish <d...@unencrypted.org> writes:
> > On Tue, Aug 04, 2009 at 10:00:24PM -0400, Tom Lane wrote:
> >> Hmm, you mean a Query, or a raw unanalyzed InsertStmt?
>
> > In this case, its a raw InsertStmt. I would like to pass this back to
> > parse_analyze, but I need to have a queryString to go with that call, so
> > crafting a function to rate that seems to be the only way, atm.
>
> Hm, so you have an InsertStmt but not the text it was generated from?
> Where? By and large the design plan is that the source text should
> still be available anyplace that's dealing with raw parsetrees.
>
> I believe you can just pass NULL as the querystring --- the only thing
> you lose from that is syntax location pointers in error messages. But
> in ordinary situations you shouldn't have to. (Also, the fact that
> that's what the string is used for means that ginning up a string from
> the nodetree is a bit pointless. It won't contain the detail that it's
> meant to provide.)
>
> regards, tom lane
Well the problem with declaring it null is that the first parse_analyze
Assert will fail.
Assert(sourceText != NULL); /* required as of 8.4 */
What I am doing here is taking one Create stmt of a new type and
breaking it up into the various operations I need it to perform. One is
a this InsertStmt. Another is a CreateStmt. I'll also need to add
CreateTrigStmt's.
Recently, I've been thinking this would be best to do
in gram.y and then pass those parts as distinct nodes. I still might hit
this queryString issue although. I haven't thought about that enough.
--
--Dan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
