Re: [HACKERS] PL/Lang (was: Priorities for 6.6)

Hannu Krosing wrote:

> What we really need is a better PL interface, the current one has
> quite a few limitations. Corba may help here, but _not_ a simple
> Corba wrapper of existing api

Actually I'm a little in doubt if calling it an interface
isn't gone too far. The only difference (from the call
handlers point of view) is that the fmgr calls one and the
same C entry point for different functions and passes
therefore the OID of the function meant. So in reality it's
more another call technique than an interface.

On the point on CORBA I say: If Someone can create a general
interface that makes integration of external
languages/applications as easy so little old ladies and 12
year old pacman players can do it, than he should. If that
new, fantastic, glory technique is based on CORBA or COBOL, I
wouln't mind - I would shout a welcome!

I'm not able to produce such a magic thing. All I can create
are things like PL/Tcl, PL/pgSQL, the actual pain of the rule
system and some other ugly ones. And as long as noone comes
up with the above peace of magic, I'll go on providing the
things I can create.

It was hard to write them, so it should be hard to use them.
I only try to make it not as hard as to learn an entirely new
language from scratch. In the PL/Tcl tree there is a little
test suite. I'm sure that a Perl expert could create the
same suite in a few minutes (like I did it) - but only in
PL/Perl - never in PL/Tcl, because then he would have a
larger learning curve ahead.

Let people use the languages they're familiar with, and
you'll get good, reliable, performat applications. Force them
to use something they've never seen before and they'll "shoot
theirself into the foot".

To understand this one someone must (re)read:

http://www.cs.rpi.edu/~edwardsb/shoot.in.foot.html

>
> > All completely non standard thing may (and should) be done outside of postgres
> > or in worst case by DYNALOAD mechanic.
>
> Currently we are doing it in your "worst case" way :)
>
> the v6.5 has even special scripts to create/destroy PLs. Only SQL and
> internal (compiled-in C) are "embedded" in non-removable way.
>
> Even PL/PGSQL must be installed to be used

And I don't think that having PL/pgSQL to follow the
generalized standard way all PL's must go is the worst case.
IMHO it's the best of all cases. Think of other standards -
ALL Windows applications must use the Windows API - except
for those created by M$. Maybe they have a good reason not to
use the Windows API - they know it's internals.

> IMHO having better support for PLs should go further than just calling
> functions in SELECT or triggers - to make it possible for people to
> easily
> add new types/indexing schemes the PL should also be usable for
> input/output
> functions, access methods and maybe even for prototyping new fe/be
> protocol.

For PL/Tcl, this time will surely come. When Tcl8.1 has
settled so 8.0 could be considered the release that has to be
supported for backward compatibility, I'll kick out the 7.6
support from PL/Tcl. This would again increase it's
performance.

The actual limitation not to be able to create data type
input/output functions is because the call handler doesn't
support it. Definitely, it could! It already has to lookup
pg_type to find the input/output functions for the return-
value/arguments. If the OID in the pg_type tuples in-/out-
function is the one the call handler actually is called for,
why not acting so?

The PL/Tcl module you're seeing with v6.5 is mainly still the
one I've developed based on Tcl7.6 (the fact that one and the
same sources actually compile with 7.6 and 8.0 stands for
itself). All the above features would have required the
Tcl_Obj interface which was new to 8.0. But at the time I
created it, 7.6 was the default in install packages of unices
and surely there where many 7.5's still in use. I decided it
would be better to first support most Tcl installations and
later force those who used it to do an upgrade.

>
> I hope to get a draft implementation of this in 6.5 before its official
> launch :)

I'll be back...

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #