Andrew Dunstan wrote:
> It could be done by putting the SPL parser in front of the SQL parser.
> Maybe Luss will tell us how it was done ;-)
We added SPL 'CREATE [OR REPLACE] PROCEDURE' and 'CREATE [OR REPLACE]
FUNCTION' Syntax support to the main scanner, parser for the backend.
By entering ex
On K, 2005-06-29 at 08:00 -0400, Dave Cramer wrote:
> This is an interesting suggestion, particularly the addition of
> additional connections for management
>
> However it does require all clients rewrite (yet again ) their
> connection code.
>
> My reasoning for suggesting a separate port f
This is an interesting suggestion, particularly the addition of
additional connections for management
However it does require all clients rewrite (yet again ) their
connection code.
My reasoning for suggesting a separate port for debugging are:
1) no changes to existing clients ( this prob
On K, 2005-06-29 at 10:33 +0100, Mark Cave-Ayland wrote:
> Hi guys,
>
> > I lean with you and Tom. While running it over the same libpq protocol
> > would be helpful in some ways, it would have a lot of drawbacks and
> > would really change the function of libpq. I think a separate debugging
Hi guys,
> I lean with you and Tom. While running it over the same libpq protocol
> would be helpful in some ways, it would have a lot of drawbacks and
> would really change the function of libpq. I think a separate debugging
> protocol is in order.
Just putting on my network hat for a momen
On Tuesday 28 June 2005 18:29, Denis Lussier wrote:
> I'm psyched for EDB to particpate and/or in some way sponsor this effort.
> How can we best help to make this a reality sooner rather than later??
>
> There's going to be a painful period later this year when Mysqueel is able
> to claim that t
> There's going to be a painful period later this year when Mysqueel
is able to claim that their production db has more ansi compatability
than PG (at least for triggers and stored procs).
MySQL5 is really comparable with Pg8, but Firebird2 or SQLlite3 too. But
from my perspective procedural l
> I lean with you and Tom. While running it over the same libpq protocol
> would be helpful in some ways, it would have a lot of drawbacks and
> would really change the function of libpq. I think a separate debugging
> protocol is in order.
>
One message? I can't belive :).
> work on it (AN
Title: Re: [HACKERS] Implementing SQL/PSM for PG 8.2 - debugger
I'm psyched for EDB to particpate and/or in some way sponsor this effort. How can we best help to make this a reality sooner rather than later??
There's going to be a painful period later this year when M
Dave,
I lean with you and Tom. While running it over the same libpq protocol
would be helpful in some ways, it would have a lot of drawbacks and
would really change the function of libpq. I think a separate debugging
protocol is in order.
Also, as far as bytecode comments go, let's separat
On Tue, 28 Jun 2005, Dave Cramer wrote:
> Pavel,
>
> I am in agreement with Tom here, we should use a separate port, and
> protocol specifically designed for this.
>
> My understanding is that this protocol would be synchronous, and be
> used for transferring state information, variables, et
Pavel,
I am in agreement with Tom here, we should use a separate port, and
protocol specifically designed for this.
My understanding is that this protocol would be synchronous, and be
used for transferring state information, variables, etc back and forth
whereas the existing protocol would
Christopher Browne <[EMAIL PROTECTED]> writes:
> There are essentially four choices:
Aside:
I suppose there are as many possible choices as there are bytecode
compiled systems out there. One could consider Icon, CLISP, Python,
PHP, OCAML, CMU/CL, all of which have bytecode compilers.
But none o
On Tue, 28 Jun 2005, Tom Lane wrote:
> Pavel Stehule <[EMAIL PROTECTED]> writes:
> >> What do you think you need for enhanced protocol ?
>
> > What I need? Some like synchronous elog(NOTICE,''), which can return some
> > user's interaction, if it's possible. I didn't find how I do it with
> > c
Pavel Stehule <[EMAIL PROTECTED]> writes:
>> What do you think you need for enhanced protocol ?
> What I need? Some like synchronous elog(NOTICE,''), which can return some
> user's interaction, if it's possible. I didn't find how I do it with
> current set of messages. But my knowleadges of prot
>
> What do you think you need for enhanced protocol ?
>
What I need? Some like synchronous elog(NOTICE,''), which can return some
user's interaction, if it's possible. I didn't find how I do it with
current set of messages. But my knowleadges of protocol are minimal.
Pavel
Pavel,
What do you think you need for enhanced protocol ?
Dave
On 28-Jun-05, at 8:51 AM, Pavel Stehule wrote:
On Tue, 28 Jun 2005, Dave Cramer wrote:
One thing bytecode would allow us to do is to write a debugger with
break points etc.
We can write debugger with breakpoints without byte
On Tue, 28 Jun 2005, Dave Cramer wrote:
> One thing bytecode would allow us to do is to write a debugger with
> break points etc.
>
We can write debugger with breakpoints without bytecode. Every stmt rec
can have flag if has breakpoints. No problem. I don't see any advance of
bytecode. Maybe,
One thing bytecode would allow us to do is to write a debugger with
break points etc.
Using a java jvm however is considerable overkill.
Dave
On 27-Jun-05, at 8:28 PM, Neil Conway wrote:
Jonah H. Harris wrote:
I don't recommend discussion for this in this thread, but it could
also tie in
On 6/28/2005 5:55 AM, Peter Eisentraut wrote:
Neil Conway wrote:
I agree the current parser is a hack, but it's difficult to see how
else it could be implemented.
Since the lexical structure of SQL/PSM seems to be about the same as the
main SQL, maybe you could get away with having the main p
Neil Conway wrote:
> I agree the current parser is a hack, but it's difficult to see how
> else it could be implemented.
Since the lexical structure of SQL/PSM seems to be about the same as the
main SQL, maybe you could get away with having the main parser just
accepting any tokens at the point
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] ("Jonah H.
Harris") wrote:
> I don't recommend discussion for this in this thread, but it could
> also tie in with the packages support we've discussed and (although
> some may argue this), compiling the PL to bytecode and using that.
On Tue, 2005-06-28 at 10:40 +1000, Neil Conway wrote:
> Jan Wieck wrote:
> > The whole parser is a hack that attempts to parse the procedural parts
> > of the function but preserving the SQL parts as query strings while
> > substituting variables with numbered parameters. That is anything but
>
Jan Wieck wrote:
The whole parser is a hack that attempts to parse the procedural parts
of the function but preserving the SQL parts as query strings while
substituting variables with numbered parameters. That is anything but
clean. It was the only way I saw at the time of implementation to bui
Jonah H. Harris wrote:
I don't recommend discussion for this in this thread, but it could also
tie in with the packages support we've discussed and (although some may
argue this), compiling the PL to bytecode and using that.
How would compilation to bytecode help?
-Neil
-
I agree with Jan,
As part of my own projects I had to deal with the PL/pgSQL parser.
While it was a workable design at the beginning, it now makes some
things harder with the quoting etc.
Don't get me wrong, I've never really had any beef with PL/pgSQL, it has
worked great for a long time b
On 6/26/2005 4:10 PM, Pavel Stehule wrote:
On Sun, 26 Jun 2005, Tom Lane wrote:
"Denis Lussier" <[EMAIL PROTECTED]> writes:
> For various technical and backward compatibility reasons, I don't think
> SQL/PSM should be a replacement for PL/pgSQL. Although I do think it
> should heavily leverag
Title: Re: [HACKERS] Implementing SQL/PSM for PG 8.2
Hi Affan,
Please read this SQL/PSM thread over and
then address how EDB did it (and of course how you would recommend generalizing
it for PG 8.2).
Perhaps our SQL/PSM could be designed from
the ground up with "debugability&qu
Alvaro Herrera wrote:
On Sun, Jun 26, 2005 at 04:44:13PM -0400, Andrew Dunstan wrote:
Is the intention here to make PSM a first class language (i.e. handled
by the main dbengine scanner/parser) of just another PL? If the latter
it seems far less worth doing. Doing this as a first class l
On Sun, Jun 26, 2005 at 04:44:13PM -0400, Andrew Dunstan wrote:
> Is the intention here to make PSM a first class language (i.e. handled
> by the main dbengine scanner/parser) of just another PL? If the latter
> it seems far less worth doing. Doing this as a first class language,
> however, wou
Is the intention here to make PSM a first class language (i.e. handled
by the main dbengine scanner/parser) of just another PL? If the latter
it seems far less worth doing. Doing this as a first class language,
however, would be great, just great.
As for pgfoundry, I think it's fair to say (
On Sun, 26 Jun 2005, Tom Lane wrote:
> "Denis Lussier" <[EMAIL PROTECTED]> writes:
> > For various technical and backward compatibility reasons, I don't think
> > SQL/PSM should be a replacement for PL/pgSQL. Although I do think it
> > should heavily leverage the solid foundation afforded by the
"Denis Lussier" <[EMAIL PROTECTED]> writes:
> For various technical and backward compatibility reasons, I don't think
> SQL/PSM should be a replacement for PL/pgSQL. Although I do think it
> should heavily leverage the solid foundation afforded by the PL/pgSQL
> code base.
"Solid"? I've wanted f
Hi All,
My company (EnterpriseDB) is very interested
in helping to make ANSI-ISO SQL Stored Procedures part of standard BSD
Postgres. The SQL/PSM standard is currently
used in DB2 and is being implemented in MySQL 5.0. Note
that I'm NOT a big fan of adding Oracle compatibility to PL/pgSQL,
34 matches
Mail list logo
