Re: function language type?

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

Responses

Browse pgsql-general by date

  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?