From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ian Turner <iant(at)mail(dot)brainstorm(dot)net> |
Cc: | Ian Turner <vectro(at)pipeline(dot)com>, pgsql-general(at)hub(dot)org |
Subject: | Re: function language type? |
Date: | 2000-07-26 14:20:45 |
Message-ID: | 10632.964621245@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ian Turner <iant(at)mail(dot)brainstorm(dot)net> writes:
>>>> with the error 'ERROR: copyObject: don't know how to copy 611'. Does this
>>>> mean one is not permitted to create tables (even temporaries!) in a
>>>> function?
>>
>> At the moment, I think not. There's no fundamental reason why it
>> couldn't be done, just some unfinished legwork (like writing a copy
>> subroutine for CreateStmt parse nodes...)
> OK. How hard would this be?
Actually I think the copyObject support may be the only missing piece.
But don't quote me.
> And just out of curiosity, why is the process different if one is in a
> function?
The issue with plpgsql is it wants to prepare a saved plan for SQL
commands, so they don't have to be re-planned on every call. So that
means copying the parser output to someplace. A lot of utility-class
statement parsenodes aren't in copyObject's repertoire for some
reason (laziness long ago no doubt).
> Can one create tables using the perl, C, or TCL interfaces?
Offhand I think this would work out-of-the-box in pltcl and plperl,
because they don't do preplanning. This is also why you can do
something like "SELECT ... FROM $1" in those PLs and not in plpgsql:
they just form the command as a string and then run it through the
whole parse/plan process every time.
And of course you can do anything you want in C, if you don't mind
the learning curve.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mitch Vincent | 2000-07-26 14:34:39 | Re: Performance for seq. scans |
Previous Message | Fabrice Scemama | 2000-07-26 14:01:18 | Is Pg 7.0.x's Locking Mechanism BROKEN? |