Re: Convert stmt back into queryString

Lists: pgsql-hackers
From: Dan Colish <dan(at)unencrypted(dot)org>
To: PGHACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Convert stmt back into queryString
Date: 2009-08-05 01:16:13
Message-ID: 20090805011613.GH3109@blackbox.spiretech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I am currently trying to convert an insertstmt back into a const
char *queryString, but I can't find an existing function to do this
for the life of me. I will write one if none exits, but I figured I
ask here first. Unfortunately, nodeToString is not quite right for
what I'm doing. Thanks in advance.

--
--Dan


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dan Colish <dan(at)unencrypted(dot)org>
Cc: PGHACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Convert stmt back into queryString
Date: 2009-08-05 02:00:24
Message-ID: 26751.1249437624@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Dan Colish <dan(at)unencrypted(dot)org> writes:
> I am currently trying to convert an insertstmt back into a const
> char *queryString, but I can't find an existing function to do this
> for the life of me. I will write one if none exits, but I figured I
> ask here first. Unfortunately, nodeToString is not quite right for
> what I'm doing. Thanks in advance.

Hmm, you mean a Query, or a raw unanalyzed InsertStmt? If the former,
ruleutils.c will help. If the latter, be prepared to write a lot of
code; there's nothing closer than nodeToString, and even that is pretty
incomplete for raw grammar output nodes IIRC.

regards, tom lane


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 02:12:43
Message-ID: 20090805021243.GN3109@blackbox.spiretech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On Tue, Aug 04, 2009 at 10:00:24PM -0400, Tom Lane wrote:
> Dan Colish <dan(at)unencrypted(dot)org> writes:
> > I am currently trying to convert an insertstmt back into a const
> > char *queryString, but I can't find an existing function to do this
> > for the life of me. I will write one if none exits, but I figured I
> > ask here first. Unfortunately, nodeToString is not quite right for
> > what I'm doing. Thanks in advance.
>
> Hmm, you mean a Query, or a raw unanalyzed InsertStmt? If the former,
> ruleutils.c will help. If the latter, be prepared to write a lot of
> code; there's nothing closer than nodeToString, and even that is pretty
> incomplete for raw grammar output nodes IIRC.
>
> regards, tom lane

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.

--
--Dan


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dan Colish <dan(at)unencrypted(dot)org>
Cc: PGHACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Convert stmt back into queryString
Date: 2009-08-05 02:55:07
Message-ID: 27974.1249440907@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


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
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