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
> > clean. It was the only way I saw at the time of implementation to build
> > a parser that automatically supports future changes of the main Postgres
> > query language.
>
> I agree the current parser is a hack, but it's difficult to see how else
> it could be implemented. One possibility I've mentioned in the past is

Could the reverse be done? Combine the PL/PgSQL and SQL grammar for the
main parser (thus allowing procedural logic in standard SQL locations)
and perhaps for the other PLs they can hook into a specific statement
grammar which is a subset of the PL/PgSQL grammar by prefixing a keyword
-- say EXECUTE to their strings.

I would like to have some logic in psql, much as you can build simple
loops and logic with shell on the command line on the fly.
--


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

A long time ago, in a galaxy far, far away, jharris@tvi.edu ("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.

This makes me think of the old jwz quote...

"Some people, when confronted with a problem, think 'I know, I'll
use regular expressions.' Now they have two problems."
-- Jamie Zawinski, on comp.lang.emacs

There are essentially four choices:

1. Embed a JVM in PostgreSQL, and use that; the fact that there are
already multiple "pljava" implementations suggests that it may be
difficult to pick a strategy...

2. Embed some clone of CLR in PostgreSQL, let's say, MONO.

I don't think there's a suitable BSDL'ed option...

3. Embed Parrot (the Perl/Python thing) in PostgreSQL. (Not that
Parrot can be considered "done".)

4. Make up a PostgreSQL-specific bytecode interpreter.

I'm quite sure that this leads to adding to the problems...
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxdatabases.info/info/nonrdbms.html
Love the scientific sampling language, when any sample that is
selected from Usenet readers and additionally self-selected is about
as representative as a wombat is of European wildlife.
-- Madeleine Page

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 where the function body belongs and
make it count BEGIN's and END's or whatever nesting elements there
might be.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 parser just
> accepting any tokens at the point where the function body belongs and
> make it count BEGIN's and END's or whatever nesting elements there
> might be.
>

Which then would require that SPI gets another interface added that
allows to feed in a token sequence instead of a query string.

After thinking more about what I wrote yesterday I noticed that we would
lose the potential for query plan recompilation after system cache
invalidation if we do not keep the queries inside of a PL function in
some sort of source code (lexer tokens still are).


Jan

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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 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
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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, goto stmt is possible.

What is problem? We need synchronous comunication (message) between
backend frontend.

I have idea (in exec_stmt()

CHECK_FOR_INTERRUPTS();
if (stmt->breakpoints)
estate->debug_mode = true;
if (estate->debug_mode)
{
for (;
{
rc = request_command();
switch (rc)
{
case 'c': -- continue
estate->debug_mode = false;
break
case 'q':
elog(EXCEPTION, "stop debug");
break;
case 'n':
break;
case 'l':
sendstring(line(estate->src,
stmt->lineno));

Please, can somebody help me with protocol enhancing? It is mayor work on
PL/pgSQL debugger (and plperl and plpython too).


> 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 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
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/docs/faq
> >
> >
>


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

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 bytecode. Every stmt
> rec
> can have flag if has breakpoints. No problem. I don't see any
> advance of
> bytecode. Maybe, goto stmt is possible.
>
> What is problem? We need synchronous comunication (message) between
> backend frontend.
>
> I have idea (in exec_stmt()
>
> CHECK_FOR_INTERRUPTS();
> if (stmt->breakpoints)
> estate->debug_mode = true;
> if (estate->debug_mode)
> {
> for (;
> {
> rc = request_command();
> switch (rc)
> {
> case 'c': -- continue
> estate->debug_mode = false;
> break
> case 'q':
> elog(EXCEPTION, "stop debug");
> break;
> case 'n':
> break;
> case 'l':
> sendstring(line(estate->src,
> stmt->lineno));
>
> Please, can somebody help me with protocol enhancing? It is mayor
> work on
> PL/pgSQL debugger (and plperl and plpython too).
>
>
>
>> 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 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
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 5: Have you checked our extensive FAQ?
>>>
>>> http://www.postgresql.org/docs/faq
>>>
>>>
>>>
>>
>>
>
>
>


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

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


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Pavel Stehule <stehule@kix.fsv.cvut.cz> 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 protocol are minimal.

It'd probably be smarter to manage the debugging across a separate
connection, so that you could carry out debugging without requiring
sophisticated support for it inside the client program. If it's
single-connection then it will be essentially impractical to debug
except from a few specialized clients such as pgadmin; which will
make it hard to investigate behaviors that are only seen under load
from a client app.

I don't know exactly how to cause such a connection to get set up,
especially remotely. But we should try to think of a way.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Tue, 28 Jun 2005, Tom Lane wrote:

> Pavel Stehule <stehule@kix.fsv.cvut.cz> 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 protocol are minimal.
>
> It'd probably be smarter to manage the debugging across a separate
> connection, so that you could carry out debugging without requiring
> sophisticated support for it inside the client program. If it's
> single-connection then it will be essentially impractical to debug
> except from a few specialized clients such as pgadmin; which will
> make it hard to investigate behaviors that are only seen under load
> from a client app.

I don't think it. Debug process halt query process in bouth variants -
remote | protocol. Remote debugging has one advance. I can monitor any
living plpgsql process, but I have to connect to some special port, and it
can be problem. Protocol debugging can be supported libpq, and all clients
libpq can debug. But is problem if PostgreSQL support bouth variants?

btw: debuging have to be only for some users,
GRANT DEBUG ON LANGUAGE plpgsql TO ..

For me, is better variant if I can debug plpgsql code in psql console.
Without spec application. I don't speak so spec application don't have to
exists (from my view, ofcourse).

Maybe:
set debug_mode to true; -- if 't' then func stmt has src
reset function myfce(integer, integer); -- need recompilation
create breakpoint on myfce(integer, integer) line 1;
select myfce(10,10);
dbg> \l .. list current line
\c .. continue
\n .. next stmt
\L .. show src
\s .. show stack
\b .. switch breakpoint
\q .. quit function
select myvar+10 .. any sql expression
variable .. print variable
\c
myfce
-----
10

that's all. Maybe I have big fantasy .

Regards
Pavel

+ small argument: if psql support debug mode, I don't need leave my emacs
postgresql mode.



>
> I don't know exactly how to cause such a connection to get set up,
> especially remotely. But we should try to think of a way.
>
> regards, tom lane
>


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)