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 adde
-- 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_tes
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
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 manual
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
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.
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. Wha
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.
>
> T
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
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
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 f
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 c
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
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
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 c
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
"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 conside
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. Drak
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 m
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 bu
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]> writ
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 w
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/mainte
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
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
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?
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 ag
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 m
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 s
29 matches
Mail list logo
