Re: Convert stmt back into queryString

From: Dan Colish <dan(at)unencrypted(dot)org>
To: PGHACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Convert stmt back into queryString
Date: 2009-08-05 03:42:54
Message-ID: 20090805034254.GA24114@funkstrom.spiretech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 04, 2009 at 10:55:07PM -0400, Tom Lane wrote:
> Dan Colish <dan(at)unencrypted(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2009-08-05 05:13:55 Re: Patch for 8.5, transformationHook
Previous Message Pavel Stehule 2009-08-05 03:34:37 Re: the case for machine-readable error fields