Re: [GENERAL] [HACKERS] plPHP in core?
In the past couple of years a lot of stuff has been removed from the core - even the ODBC driver (which is ways more important than, let's say, PL/PHP) has been removed from the core - so why should a new PL be integrated now if considerably more important components will remain external? Best regards, Hans Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: I'm not convinced that PLs are more tied to the core than say OpenFTS, and if we can't maintain that kind of thing externally, then this whole extension thing sounds like a failure to me. It's *possible* to do it. Whether it's a net savings of effort is questionable. For instance, I've had to hack plperl and plpgsql over the past couple days to support OUT parameters, and the only reason I didn't have to hack the other two standard PLs is that they are a few features shy of a load already. I'm pretty sure pl/r and pl/java will need changes to support this feature too. If they were in core CVS then I'd consider it part of my responsibility to fix 'em ... but they aren't, so it isn't my problem, so it falls on Joe and Thomas to get up to speed on what I've been doing and do likewise. Is that really a win? The point here is really that we keep finding reasons to, if not flat-out change the interface to PLs, at least expand their responsibilities. Not to push it too hard, but we still have only one PL with a validator procedure, which IIRC was your own addition to that API. How come they don't all have validators? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/664/393 39 74 www.cybertec.at, www.postgresql.at ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[GENERAL] Accessing the execution plan via the DBI interface
Is there a way to access the execution plan of a query using the DBI interface? Since EXPLAIN seems to write to STDERR, there is no way to use prepare->execute->fetch ... Does anybody know, what to do best - I don't want to use a system call from inside Perl. Hans ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[GENERAL] Re: Compile PL/Perl
Hans-Jürgen Schönig schrieb: Does anyone know why perl Makefile.pl doesn't produce a useful Makefile with RedHat 7.0 (Perl 5.6) and PostgreSQL 7.0.3? Hans After some hard hours of debugging and testing I finally found out that it seems to work with Perl 5.005 but NOT with Perl 5.6. Hans -- --- Cybertec Geschwinde &. Schönig OEG; Schönbrunnerstraße 133/18 A-1050 Wien; http://postgres.cybertec.at; Fax.: +43/1/961 71 58 Tel.: +43/664/233 90 75
[GENERAL] Compile PL/Perl
Does anyone know why perl Makefile.pl doesn't produce a useful Makefile with RedHat 7.0 (Perl 5.6) and PostgreSQL 7.0.3? Hans ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[GENERAL] Problem with PL/pgSQL
What is wrong with the following function? CREATE FUNCTION logfunc2 (text) RETURNS int AS ' DECLARE text ALIAS FOR $1; BEGIN SELECT length(text); RETURN ''3''; END; ' LANGUAGE 'plpgsql'; I get the following error: ERROR: Unrecognized language specified in a CREATE FUNCTION: 'plpgsql'. Recognized languages are sql, C, internal, and created procedural languages. According to my docs "plpgsql" should be ok. Hans
Re: [GENERAL] Large files on linux
Alfred Perlstein schrieb: > * Fernan Aguero <[EMAIL PROTECTED]> [001211 12:45] wrote: > > Dear all: > > > > I am having trouble with large files on a Linux box (RH 6.2). I know there > > is a limit of 2 GB on the file size, but do not know if this is kernel > > related, filesystem related or both. > > Afaik it's both. > > Honestly Postgresql should be able to deal with this limitation by > using more than one file per table. > > But if you really want to support large files on a free UNIX, > I'd try FreeBSD. > > best of luck, > -- > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > "I have the heart of a child; I keep it in a jar on my desk." Kernel >= 2.4 can manage large files. As far as I have tried this it works perfectly well. Hans
