Is there any documentation that describes how to use the SQL
functions? Some are obvious enough, but a simple example showing a
debugging session would be helpful.
John, I started writing up the API documentation and then noticed that
most of what I intended to write is already described in
Since my version of pg is built with VC++ I thought it wise to also
use VC++ for the debugger plugin. So I converted the Makefile into 3
different VC++ projects - pldbgapi, plugin_debugger and targetinfo.
Note that targetinfo is not mentioned at all in the comments at the
top of Makefile -
Is there any documentation that describes how to use the SQL
functions? Some are obvious enough, but a simple example showing a
debugging session would be helpful.
I'll add that to the README file and let you know when it's ready.
-- Korry
---(end of
Now that we've announced (see
http://www.informationweek.com/news/showArticle.jhtml?articleID=201803375subSection=News)
that 8.3 will include a debugger (don't worry, it's a PL/pgSQL debugger
:-), has anyone actually tried it yet (other than myself and Dave Page)?
I would appreciate any
Now that we've announced
Could you please define we? Is it EDB or PostgreSQL ? I'm asking
this per a thread @ -advocacy list.
That -advocacy thread is what got me started. I was referring to the
interview in InformationWeek - that's a PG-related interview not an
EDB-related
In any case, it's a plugin for PostgreSQL 8.2 and above that allows
you to debug pl/pgsql functions using pgAdmin.
Yes I know and spent a bit time for testing it -- but not much.
Devrim, does that mean that you've tried it and it seemed to work? Did
you try it with 8.2 or 8.3?
1. can be integrated into psql?
There is an API - I wouldn't want to try to use it from the
command-line, but you certainly can. You would call functions such as:
SELECT * FROM pldbg_set_breakpoint( 'myfunction' );
SELECT * FROM pldbg_wait_for_breakpoint( ... );
SELECT * FROM
Yeah, I think so. The PL/pgSQL debugger was part of a list of 14-15 features
I gave Charles Babcock; not sure why he liked that one, but he did.
Last I talked to Korry, it was ready to go. No?
If by ready to go you mean has been exercised by a mess o' people, no.
If by ready to go you
The interview made it sound more mainstream. But then it did sound a
little disjointed too.
I suspect that it may go more mainstream in a later release, but it
seems way too late for 8.3.
Do we know if it going to be distributed with pgAdmin on Windows?
The graphical debugger client is part
The core of the debugger has been in use for quite some time, but I
had to strip out a lot of EDB-specific code and I'd like to see that
the result (the open-source version at pgFoundry) holds up well on
other platforms.
Josh, any chance you could try it out on Solaris?
I copied the latest
What if we just defined the binary format as being identical to the text
format, ie, the enum label? A bit silly but at least it would eliminate
the gotcha that binary I/O fails.
Seems like it would make a lot more sense to the client application that
way too...
-- Korry
the idea is basically to hide codes - many companies want that and ask
for it again and again.
Hide code from who (or is that whom?)? The PL compiler(s) will need to
decrypt the code. If a compiler can decrypt it, then anyone can decrypt
it (because the compilers are open-source).
And the
My suggestion is to extend PL API and each PL language should offer
wrap or encrypt function which generate encrypted code and this code
will be store in the pg_proc. PL language will be responsible to
detect if it raw or crypted code. PG_Dump will dump crypted procedure
and author is
I have not yet succeeded in turning this behaviour off (_setmode()
didn't seem to affect it). If we can't find a way to turn it off, the
only solution short of abandoning its use on Windows that I can think
of is to translate LF on input to something unlikely like 0x1C and
then translate it
I have not yet succeeded in turning this behaviour off (_setmode()
didn't seem to affect it). If we can't find a way to turn it off, the
only solution short of abandoning its use on Windows that I can think
of is to translate LF on input to something unlikely like 0x1C and
then translate it
15 matches
Mail list logo
