Re: [HACKERS] [GENERAL] plPHP in core?
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? So far we've been able to keep up with PostgreSQL changes because a) the interfaces are after all pretty well defined, and b) there is always a long enough delay between changes of the interfaces and their official release to make it possible for us to catch up. Cumbersome sure, but still not my primary concern. There's a couple of other reasons why it's bad to be an "outsider". a) If skilled core developers from time to time stumbled on compilation errors in PL/Java due to changes made in the backend, then I believe that this would result in some level of code review and perhaps lots of good criticism and ideas of improvement. b) I've been forced to do pull some tricks in PL/Java to work around things that I consider lacking in the interfaces. Having PL/Java in core would make it possible to work together more tightly in order to find good solutions/API's that can benefit all PL's. c) PL/Java would become (optional?) part of the build and the regression tests. It would be great to get early warnings when things change that break PL/Java. d) Bringing PL/Java into core will force a consistent documentation and, I imagine, a chapter of it's own in the main docs. I'm happy to write most of it but English is not my native language. Whatever I put into print will always benefit from a review. e) The article http://www.powerpostgresql.com/5_types describes another serious issue pretty well. While it's easy for an organization to become dependent on the "Community" based PostgreSQL, it's much more difficult to make such a decision with the "Solo" based PL/Java. In essence, I'm all for bringing PL/Java into core. While doing so I think it's imperative to maintain good API's between modules and backend. Bringing the PL's into core must be done while retaining good separation of concern. The extension mechanism is a good thing. It should be improved regardless where PL's end up. 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? For PL/Java, the answer is that we just haven't had the time to implement it. It should be done of course. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] LEFT JOIN used in psql describe.c
Tom Lane wrote: > "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes: > >> Does anyone know why so many LEFT JOINs are used in psql/describe.c to > >> join to the pg_namespace table, like here: > > > Yes, pg_relnamespace is definitely not null. I've actually already removed > > the left joins from my \df patch, since I had to rewrite some of the > > queries anyway. If this is wrong, please let me know of course! > > I think the idea was to be certain to show every pg_proc entry (or other > catalog for other \d commands), no matter how badly broken the catalog > interrelationships might be. If there's not an unarguable reason > for eliminating the left joins I'd be inclined to keep it like that. > What does an inner join buy here, other than brittleness? > > (Yeah, I have the perspective of a developer who deals with broken > situations every day. So?) If we have problems with the system catalogs, I don't see how this join has a high probability of catching the problem. If there was some known problem of the join not always working, I could see the use of LEFT JOIN, but there isn't, so it just seems confusing, and these queries are used by others as models of how to do system joins, so could confuse our users as well. I think the LEFT JOIN should be removed unless there is a known problem, and if one shows up, we can re-add them later. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] plPHP in core?
Peter Eisentraut wrote: Joshua D. Drake wrote: We at Command Prompt are in the process of completing a new rev of plPHP. The new rev will not require the PHP source. It will only require that PHP is installed. How can that be? I am not sure I understand the question but we are linking against the .so now. So as long as PHP is and PostgreSQL ./configure knows where to look we should be good. Sincerely, Joshua D. Drake Are we interested in having plPHP in core? Personally, I'm not too excited about it. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(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
Re: [HACKERS] [GENERAL] plPHP in core?
Joshua D. Drake wrote: > I am not sure I understand the question but we are > linking against the .so now. So as long as PHP > is and PostgreSQL ./configure knows where to look > we should be good. The question is, how can you build a PL/something module without having "something" installed at build time? One would assume that such code needs to include some header files and link with a library. I'm just curious about how you pulled that off. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
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 8: explain analyze is your friend
Re: [GENERAL] [HACKERS] plPHP in core?
pl-j ( the other java procedural language ) is definately interested in being in core. Dave Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> writes: On Fri, 1 Apr 2005, Joshua D. Drake wrote: Are we interested in having plPHP in core? Is there a reason why it can no longer operate as a standalone language out of pgfoundry, like pl/java and pl/perl? PLs are sufficiently tightly tied to the core that it's probably easier to maintain them as part of our core CVS than otherwise. (Ask Joe Conway about PL/R. Thomas Hallgren is probably not that happy about maintaining pl/java out of core, either. And pl/perl *is* in core.) I'm thinking that a pl/PHP is much more interesting for the long term than, say, pl/tcl (mind you, I am a Tcl partisan from way back, but I see that many people are not so enlightened). Barring any licensing problems I think this is something to pursue. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] plPHP in core?
Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> writes: Also, since plPerlNG is maintained on PgFoundry, are the changes you are making to core getting migrated back to the main project itself? I don't know, and not being a maintainer of the pgfoundry project, it is *definitely* not my problem. But I cannot believe it's a good idea to have two supposedly authoritative CVS repositories for the same code... Core is the authoritative repo for plPerl. pgFoundry is our R&D... our Linux 2.1 versus 2.2. Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] [HACKERS] plPHP in core?
Marc G. Fournier wrote: One key point to note here is Joshua already saying they wish, like plPerl, to continue maintaining the "core code" outside of the core distribution ... the way I read that is they just want to be 'in core' to piggy back on the distribution, not to make development/maintenance any easier ... Well that is not exactly what I meant but I see what you are saying. The reason plPerlNG is maintained outside of core and then resubmitted is that we worked on it longer than feature freeze and we made the features work with 7.4 as well. We have not done any work on it, in about 6 months?... I am thinking. ey 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, why should it be your responsibility to fix 'em? This is a good point and I did submit to Tom that as we were the ones that submitted the new plPerl that we would have been happy to do that work. We just didn't know the work was being done. Is it really a win that the only person 'up to speed' that can fix them is you? Seems a load that will grow heavier as more PLs (if more PLs) come online ... This argument doesn't hold too much weight. Namely because there are only 3-5 really popular languages out there. They are marketing languages. The are languages you include because your database doesn't "sound" complete with out them. Regardless if you can download them separately. People are lazy. They don't want to download them separately. I see those as: plPgsql (for Oracle people) plPerl plPHP plJava plPython is cool and all (I love Python) but feature wise it is quite a bit behind the others and unless someone picks up active development it probably should be removed. FYI: Resources permitting we are looking at plPython If plJava can be integrated in a way that will allow it to be installed easily with the standard mechanism of ./configure --with-pljava then I believe it should be there as well. Also, since plPerlNG is maintained on PgFoundry, are the changes you are making to core getting migrated back to the main project itself? I have not see a patch yet. Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] [HACKERS] plPHP in core?
Hans-Jürgen Schönig wrote: 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? ODBC is a client side driver. It is not a server side driver. It does not require PostgreSQL to be installed. plPHP, plPerl, etc... all require PostgreSQL, they are a part of PostgreSQL whether in core or not. Sincerely, Joshua D. Drake 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 -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] plPHP in core?
Dave Cramer wrote: pl-j ( the other java procedural language ) is definately interested in being in core. Is it actively developed? Not being rude... I just haven't heard much (almost nothing) about it. Sincerely, Joshua D. Drake Dave Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> writes: On Fri, 1 Apr 2005, Joshua D. Drake wrote: Are we interested in having plPHP in core? Is there a reason why it can no longer operate as a standalone language out of pgfoundry, like pl/java and pl/perl? PLs are sufficiently tightly tied to the core that it's probably easier to maintain them as part of our core CVS than otherwise. (Ask Joe Conway about PL/R. Thomas Hallgren is probably not that happy about maintaining pl/java out of core, either. And pl/perl *is* in core.) I'm thinking that a pl/PHP is much more interesting for the long term than, say, pl/tcl (mind you, I am a Tcl partisan from way back, but I see that many people are not so enlightened). Barring any licensing problems I think this is something to pursue. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] Debugging deadlocks
On Fri, Apr 01, 2005 at 11:02:36PM -0500, Tom Lane wrote:
[Cc: to -hackers]
> We currently store tuple locks on the same page as the tuples (ie, in
> the tuple headers) and need no extra locks to do so. Certainly it
> still has to have a spill mechanism, but the thought that is attractive
> to me is that until you are forced to spill, you do not have to take any
> system-wide lock, only a page-level lock. So it could have very good
> average performance.
If we go this way maybe we should abandon the idea of using the standard
lock manager to lock tuples, which is what can be found on the patch I
posted. Or maybe not, and just have the lock manager store the locks on
the page himself -- but it will have to know about the buffer, so it
will be in some sense a break in opacity (of API between the two).
One possible way to do it would be having a OffsetNumber stored in the
page header, and if it's not InvalidOffsetNumber then it points to a
"tuple" that holds
struct
{
OffsetNumber nextLock;
LOCK lock
}
So a locker would check the chain of locks and stop when it sees
InvalidOffsetNumber.
If there is no free space on the page, what should we do? Store the
lock into the main hash table?
Another problem would be the XLog. On heap operations, do we register
exactly where (position in the page) a tuple was stored, or just the
fact that it was stored? If the latter, then there's no problem. If
the former, then on the next REDO the records wouldn't match (==> PANIC)
-- unless we logged the lockings as well.
Reading the code I see we do log the offset numbers, so that's a problem
:-( ... maybe we could work around that by moving the pd_lower without
using line pointers; not sure if that's doable.
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Porque Kim no hacia nada, pero, eso sí,
con extraordinario éxito" ("Kim", Kipling)
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] [HACKERS] plPHP in core?
Very actively, http://plj.codehaus.org Dave Joshua D. Drake wrote: Dave Cramer wrote: pl-j ( the other java procedural language ) is definately interested in being in core. Is it actively developed? Not being rude... I just haven't heard much (almost nothing) about it. Sincerely, Joshua D. Drake Dave Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> writes: On Fri, 1 Apr 2005, Joshua D. Drake wrote: Are we interested in having plPHP in core? Is there a reason why it can no longer operate as a standalone language out of pgfoundry, like pl/java and pl/perl? PLs are sufficiently tightly tied to the core that it's probably easier to maintain them as part of our core CVS than otherwise. (Ask Joe Conway about PL/R. Thomas Hallgren is probably not that happy about maintaining pl/java out of core, either. And pl/perl *is* in core.) I'm thinking that a pl/PHP is much more interesting for the long term than, say, pl/tcl (mind you, I am a Tcl partisan from way back, but I see that many people are not so enlightened). Barring any licensing problems I think this is something to pursue. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(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
Re: [HACKERS] invalidating cached plans
"Qingqing Zhou" <[EMAIL PROTECTED]> writes: > "Neil Conway" <[EMAIL PROTECTED]> writes >> PostgreSQL should invalidate a cached query plan when one of the objects >> the plan depends upon is modified. > It just comes into my mind that current cache invalidation implementation > may need to consider the future query result cache. There isn't likely ever to be a query result cache. The idea has been proposed before and rejected before: too much complexity and overhead for too little prospective gain. If you need such a thing it makes more sense to do it on the application side and save a network round trip. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] plPHP in core?
On Sat, 2 Apr 2005, Peter Eisentraut wrote: Joshua D. Drake wrote: I am not sure I understand the question but we are linking against the .so now. So as long as PHP is and PostgreSQL ./configure knows where to look we should be good. The question is, how can you build a PL/something module without having "something" installed at build time? One would assume that such code needs to include some header files and link with a library. I'm just curious about how you pulled that off. Oh you do need PHP installed you just don't need the source. As everyone knows ;) I am not a c-programmer and I do not know the finer details. I can of course find out from my developers. Sincerely, Joshua D. Drake -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] plPHP in core?
Joshua D. Drake wrote: > Oh you do need PHP installed you just don't need the source. As > everyone knows ;) I am not a c-programmer and I do not know the finer > details. I can of course find out from my developers. Well, that doesn't solve the circular build dependency issue then. Before you can install PHP you already need PostgreSQL (libpq) installed. So nothing relevant to that issue has changed, as far as I can see. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] plPHP in core?
On Sat, 2 Apr 2005, Peter Eisentraut wrote: Joshua D. Drake wrote: Oh you do need PHP installed you just don't need the source. As everyone knows ;) I am not a c-programmer and I do not know the finer details. I can of course find out from my developers. Well, that doesn't solve the circular build dependency issue then. Before you can install PHP you already need PostgreSQL (libpq) installed. So nothing relevant to that issue has changed, as far as I can see. Uhhmmm no? You only need libpq installed if you want postgresql client side support but I will double check. Actually as I think about it... that is not the case even now. When we download the php source the base configure before compile is: ./configure --disable-all Thus no use of PostgreSQL whatsoever. Sincerely, Joshua D. Drake -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] plPHP in core?
Joshua D. Drake wrote: > Actually as I think about it... that is not the case even now. When > we download the php source the base configure before compile is: > > ./configure --disable-all > > Thus no use of PostgreSQL whatsoever. I'm sure it is possible to get around it manually, but think about distributors. They probably compile PHP more to the tunes of --enable-everything. I don't think they will like it if we tell them that they need to switch to a two-stage build process or something. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] plPHP in core?
On Sat, 2 Apr 2005, Joshua D. Drake wrote: This argument doesn't hold too much weight. Namely because there are only 3-5 really popular languages out there. They are marketing languages. The are languages you include because your database doesn't "sound" complete with out them. Regardless if you can download them separately. People are lazy. They don't want to download them separately. Actually, as I've stated many times before, and why I continue to argue against the "mega distribution", I *know* that ppl using the *BSDs download them indivdually, as that is how our ports are built: drwxr-xr-x 2 root wheel 512 Feb 4 04:59 p5-postgresql-plperl drwxr-xr-x 2 root wheel 512 Feb 4 04:59 postgresql-plpython drwxr-xr-x 3 root wheel 512 Jan 31 04:59 postgresql-plruby drwxr-xr-x 2 root wheel 512 Feb 4 04:59 postgresql-pltcl Unless postgresql isn't already installed ... In fact, a total break down right now o four ports looks like: drwxr-xr-x 2 root wheel 512 Feb 4 04:59 p5-postgresql-plperl drwxr-xr-x 2 root wheel 512 Feb 4 04:59 postgresql-contrib drwxr-xr-x 3 root wheel 512 Jan 24 04:59 postgresql-devel drwxr-xr-x 2 root wheel 512 Jan 31 04:59 postgresql-docs drwxr-xr-x 3 root wheel 512 Feb 11 04:59 postgresql-jdbc drwxr-xr-x 3 root wheel 512 Jan 31 04:59 postgresql-libpq++ drwxr-xr-x 3 root wheel 512 Jan 31 04:59 postgresql-libpqxx drwxr-xr-x 2 root wheel 512 Dec 6 04:59 postgresql-odbc drwxr-xr-x 2 root wheel 512 Feb 4 04:59 postgresql-plpython drwxr-xr-x 3 root wheel 512 Jan 31 04:59 postgresql-plruby drwxr-xr-x 2 root wheel 512 Feb 4 04:59 postgresql-pltcl drwxr-xr-x 3 root wheel 512 Dec 14 05:01 postgresql-relay drwxr-xr-x 3 root wheel 512 Feb 20 04:59 postgresql-tcltk drwxr-xr-x 2 root wheel 512 Feb 20 04:59 postgresql73-client drwxr-xr-x 3 root wheel 1024 Mar 19 04:59 postgresql73-server drwxr-xr-x 2 root wheel 512 Feb 20 04:59 postgresql74-client drwxr-xr-x 3 root wheel 1024 Mar 19 04:59 postgresql74-server drwxr-xr-x 2 root wheel 512 Feb 20 04:59 postgresql80-client drwxr-xr-x 3 root wheel 1024 Mar 19 04:59 postgresql80-server drwxr-xr-x 2 root wheel 512 Oct 24 04:59 postgresql_autodoc Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] plPHP in core?
Thomas Hallgren wrote: Tom Lane wrote: 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? So far we've been able to keep up with PostgreSQL changes because a) the interfaces are after all pretty well defined, and b) there is always a long enough delay between changes of the interfaces and their official release to make it possible for us to catch up. Cumbersome sure, but still not my primary concern. There's a couple of other reasons why it's bad to be an "outsider". This has also been my experience. Every Postgres development cycle has seen a half dozen or so backend changes that break PL/R. It usually doesn't take too long to respond to the changes though. a) If skilled core developers from time to time stumbled on compilation b) I've been forced to do pull some tricks in PL/Java to work around c) PL/Java would become (optional?) part of the build and the regression d) Bringing PL/Java into core will force a consistent documentation and, Agreed. e) The article http://www.powerpostgresql.com/5_types describes another serious issue pretty well. While it's easy for an organization to become dependent on the "Community" based PostgreSQL, it's much more difficult to make such a decision with the "Solo" based PL/Java. This one is particularly important. I'm currently responsible for a commercial project at work that sits on the shoulders of a good deal of open source software. We've specifically needed to either avoid components with single or a small number of maintainers, or make a conscious decision to accept permanent responsibility to maintain the code should the "Solo" disappear (and dedicate enough resource to become comfortable with that code). Like it or not, I think everything relegated to pgfoundry suffers from this to some degree. There is no doubt in my mind that both PL/R and PL/Java would get much wider use (and therefore wider testing and code review) if they were packaged with the core Postgres distribution. 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? For PL/Java, the answer is that we just haven't had the time to implement it. It should be done of course. Agreed. Time has been hard for me to come by lately :( Joe ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] plPHP in core?
On Sat, 2 Apr 2005, Thomas Hallgren wrote: b) I've been forced to do pull some tricks in PL/Java to work around things that I consider lacking in the interfaces. Having PL/Java in core would make it possible to work together more tightly in order to find good solutions/API's that can benefit all PL's. Submitting bug reports, or asking on -hackers, would have the same effect ... d) Bringing PL/Java into core will force a consistent documentation and, I imagine, a chapter of it's own in the main docs. I'm happy to write most of it but English is not my native language. Whatever I put into print will always benefit from a review. There is nothing stop'ng a chapter being added now, and a pointer to where to download it could be easily added as part of it .. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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
Re: [GENERAL] [HACKERS] plPHP in core?
On Sat, 2 Apr 2005, Dave Cramer wrote: pl-j ( the other java procedural language ) is definately interested in being in core. Yet anothre good reason *not* to be including PLs ... similar to why we moved libpq++ out of core ... I may be wrong, but I doubt that pl-j has the same feature set as pl-java, or vs versa ... so, what do we do? each time someone argues for a better widget, we swap out the old and include the new? there is no guarantee that plPHP will be the only PHP based PL out there, any more then the other PLs, or language libraries ... *If* something *requires* the physical postgresql source code to be available (not just the isntalled headers/libraries), like libpq does, then it makes sense to be part of the core distribution ... but, IMHO, the core distribution shouldn't be 'the means to validation' of an interface, since it unfairly negates work that someone else might be working on (ie. in this case, Dave's pl-j alternative to pl-java) ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [GENERAL] plPHP in core?
Marc G. Fournier wrote: > > d) Bringing PL/Java into core will force a consistent documentation > > and, I imagine, a chapter of it's own in the main docs. I'm happy > > to write most of it but English is not my native language. Whatever > > I put into print will always benefit from a review. > > There is nothing stop'ng a chapter being added now, Actually there is: We don't ship documentation for software that we don't ship. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [GENERAL] plPHP in core?
On Sat, 2005-04-02 at 21:48 +0200, Peter Eisentraut wrote: > Marc G. Fournier wrote: > > > d) Bringing PL/Java into core will force a consistent documentation > > > and, I imagine, a chapter of it's own in the main docs. I'm happy > > > to write most of it but English is not my native language. Whatever > > > I put into print will always benefit from a review. > > > > There is nothing stop'ng a chapter being added now, > > Actually there is: We don't ship documentation for software that we > don't ship. Very well, rephrase that a little. There is nothing stopping additional links to documentation from being added to the PostgreSQL website in the documentation section. -- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] plPHP in core?
Rod Taylor wrote: > There is nothing stopping additional links to documentation from > being added to the PostgreSQL website in the documentation section. That is true, but that does not foster consistent documentation, which is what Thomas Hallgren wanted. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] plPHP in core?
On Sat, 2 Apr 2005, Peter Eisentraut wrote: Rod Taylor wrote: There is nothing stopping additional links to documentation from being added to the PostgreSQL website in the documentation section. That is true, but that does not foster consistent documentation, which is what Thomas Hallgren wanted. I know that you are working on a pgtranslation project thruogh pgfoundry ... would it be an idea to maybe setup a 'documentation framework/skeleton' that other projects could use to base their docs on? In fact, just coming to mind, GNUs info documentation ... when I add a new GNU product to the server ,it gets 'auto-added' to the main index page, and have similar/same formats to give a consistency across different pieces of software ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] plPHP in core?
Peter Eisentraut wrote: Joshua D. Drake wrote: Actually as I think about it... that is not the case even now. When we download the php source the base configure before compile is: ./configure --disable-all Thus no use of PostgreSQL whatsoever. I'm sure it is possible to get around it manually, but think about distributors. They probably compile PHP more to the tunes of --enable-everything. I don't think they will like it if we tell them that they need to switch to a two-stage build process or something. Well I can't speak to anything but Linux. Most Linux distributions (at least the significant ones) break PHP up into several different packages and things like mysql and php are specifically different packages. Yes those packages would require libpq but that has nothing to do with plPHP. Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] plPHP in core?
On Sat, 2 Apr 2005, Joshua D. Drake wrote: Peter Eisentraut wrote: Joshua D. Drake wrote: Actually as I think about it... that is not the case even now. When we download the php source the base configure before compile is: ./configure --disable-all Thus no use of PostgreSQL whatsoever. I'm sure it is possible to get around it manually, but think about distributors. They probably compile PHP more to the tunes of --enable-everything. I don't think they will like it if we tell them that they need to switch to a two-stage build process or something. Well I can't speak to anything but Linux. Most Linux distributions (at least the significant ones) break PHP up into several different packages and things like mysql and php are specifically different packages. This is correct for FreeBSD also ... you build a 'central php' and add modules as seperate ports that are enabled thorugh an extensions.ini file ... Same thing happens with the various 'components' of postgresql, each are built/installed as seperate packages, where if the appropriate headers are already installed on teh machine, the core distribution doesn't have to be re-downloaded/extracted ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] how can I use a bound cursor
-- I ' ll use a bound cursor, bun when I execute following cursor-- I met a error message within for loop-- Help me...CREATE OR REPLACE FUNCTION cursor_test( vp_param1 VARCHAR ,vp_param2 VARCHAR)RETURNS VARCHAR AS $BODY$DECLARE p_param1 VARCHAR; p_param1 VARCHAR; cur_test CURSOR (c_param VARCHAR) IS SELECT col_1, col_2, col_3 FROM tab_1 WHERE col_1 = c_param; rec_test RECORD; v_count NUMERIC;BEGIN p_param1 := nullif(vp_param1 , ''); p_param2 := nullif(vp_param2 , ''); IF p_param1 = 'txn' THEN - -- 커서처리 - OPEN cur_test(p_param2); for rec_test in cur_test loop --FETCH cur_test INTO rec_test; SELECT count(*) INTO v_count FROM tab_2 WHERE col_1 = rec_test.col_1 and col_2 = rec_test.col_2 ; IF v_count >0 THEN insert into tab_2 ( col_1 , col_2 , col_3 ) values ( rec_test.col_1 , rec_test.col_2 , rec_test.col_3 ); END IF; end loop; -- cur_test 커서처리 CLOSE cur_test; END IF; RETURN '처리완료';END;$BODY$ LANGUAGE plpgsql;
Re: [HACKERS] [GENERAL] plPHP in core?
d) Bringing PL/Java into core will force a consistent documentation and, I imagine, a chapter of it's own in the main docs. I'm happy to write most of it but English is not my native language. Whatever I put into print will always benefit from a review. There is nothing stop'ng a chapter being added now, Actually there is: We don't ship documentation for software that we don't ship. How about we start a new standard extensions manual on pgFoundry, and give the documentors from all the main extension projects commits on it. That way it's all in one place :) Or at least a PL's manual... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
