Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, this is a little off-the-wall, but one interesting idea to help SQL
> and PL/foo integration would be to replace the bison grammar for SQL
> with a hand-written recursive descent parser.
Ick. I gave up hand-written RD parsers twenty-five years ago.
David Fetter wrote:
EXECUTE IMMEDIATE $$
function body here
$$
LANGUAGE plfoo;
Seems like a lot of unnecessary syntax for something that would be
manually used by a lot of DBAs. Also, this is unrelated to normal
EXECUTE, or the EXECUTE IMMEDIATE defined by the standard, so I'm not
sure it's
On Mon, May 09, 2005 at 05:28:42PM -0600, Jonah H. Harris wrote:
> David,
>
> I agree with your idea. That seems like it would be somewhat easy to
> implement and would do exactly what I would need. Anyone else have
> ideas or thoughts along this line?
Seeing as EXECUTE IMMEDIATE is already u
David,
I agree with your idea. That seems like it would be somewhat easy to
implement and would do exactly what I would need. Anyone else have
ideas or thoughts along this line?
David Fetter wrote:
On Mon, May 09, 2005 at 11:44:23AM -0600, Jonah H. Harris wrote:
Hey everyone,
In addition to
On Mon, May 09, 2005 at 11:44:23AM -0600, Jonah H. Harris wrote:
> Hey everyone,
>
> In addition to package support in plpgsql, it would be really handy
> to have inline plpgsql. Likewise, I think there are others who feel
> this way as-well.
Why yes, there are. :)
> Years ago, Oracle merged PL
On E, 2005-05-09 at 11:44 -0600, Jonah H. Harris wrote:
> Hey everyone,
>
> In addition to package support in plpgsql, it would be really handy to
> have inline plpgsql. Likewise, I think there are others who feel this
> way as-well.
Session variables is what I miss most.
> Years ago, Oracle
Joshua D. Drake wrote:
As for implementation, I think it would obviously be best to leave
plpgsql on its own as a PL but maybe change BEGIN and DECLARE in the
normal parser and have the system generate/execute a function on the
fly. Or, maybe it would be better to integrate plpgsql. Or, I may
Jonah,
> In addition to package support in plpgsql, it would be really handy to
> have inline plpgsql. Likewise, I think there are others who feel this
> way as-well.
I think a number of people would be interested in this. However, your
biggest development issue, as I've been told, is that th
As for implementation, I think it would obviously be best to leave
plpgsql on its own as a PL but maybe change BEGIN and DECLARE in the
normal parser and have the system generate/execute a function on the
fly. Or, maybe it would be better to integrate plpgsql. Or, I may just
be crazy.
Would
