I am thinking we should allow exit by falling off the end of the
function when (a) it has output parameter(s), or (b) it is declared
"RETURNS void". Comments?
I agree - makes sense.
Chris
---(end of broadcast)---
TIP 6: Have you searched our list arc
As of CVS tip, plpgsql handles output parameters, in the style
CREATE FUNCTION sum_n_product(x int, y int, OUT sum int, OUT prod int) AS $$
BEGIN
sum := x + y;
prod := x * y;
RETURN;
END;
$$ LANGUAGE plpgsql;
The RETURN statement is kinda useless in this example, but it is still
requi
On Tue, Apr 05, 2005 at 11:46:22AM +0800, Christopher Kings-Lynne wrote:
> pgfoundry.org and www.pgfoundry.org currently redirect to hub.org...
They both work for me ...
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen...
Hmmm, seems to have been fixed now...
Christopher Kings-Lynne wrote:
pgfoundry.org and www.pgfoundry.org currently redirect to hub.org...
Chris
---(end of broadcast)---
TIP 8: explain analyze is your friend
---(end of broadcast
On Mon, Apr 04, 2005 at 11:32:47PM -0400, Greg Stark wrote:
>
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > Using Phantom Xids
> > ==
> > The idea here is to use an approach similar to what we use now: mark the
> > tuples with an Xid when it is locked. A phantom Xid is a sor
pgfoundry.org and www.pgfoundry.org currently redirect to hub.org...
Chris
---(end of broadcast)---
TIP 8: explain analyze is your friend
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Because those other languages are well designed and PHP is not. The
> Postgres support package for Perl is a completely separate add-on, which
> you can add well after the core of Perl is installed. Same for Python.
> But PHP is a braindead package wh
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Using Phantom Xids
> ==
> The idea here is to use an approach similar to what we use now: mark the
> tuples with an Xid when it is locked. A phantom Xid is a sort-of Xid,
> with multiple real Xids associated to it. So we mark the tupl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[ CC'ing hackers to see if anyone else wants to weigh in ]
Tom Lane wrote:
Of course, the entire reason this didn't happen years ago is that we
couldn't agree on what keyword to use... you sure you want to reopen
that discussion?
Sure, it doesn't seem too difficult to settle to me.
I don't think ch
On Mon, 2005-04-04 at 16:27 -0400, Alvaro Herrera wrote:
> On Mon, Apr 04, 2005 at 07:08:11PM +0100, Simon Riggs wrote:
>
> > IIRC there is not another major system that spills locks to disk and
> > there's a big reason: performance is very poor. Other systems accept
> > some limitations in order
Alvaro Herrera wrote:
On Mon, Apr 04, 2005 at 04:48:50PM -0400, Robert Treat wrote:
The problem is that even if you could build a Postgres support package
for PHP without building the whole PHP (which you _can_ do AFAIK), it
means that you need to make a second pass at the PHP source RPM, which
On Mon, 2005-04-04 at 17:00, Doug McNaught wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
>
> > If by "stripped down" you mean without postgresql database support then
> > I'll grant you that, but it is no different than other any other pl
> > whose parent language requires postgresql to be ins
On Mon, 2005-04-04 at 17:03, Alvaro Herrera wrote:
> On Mon, Apr 04, 2005 at 04:48:50PM -0400, Robert Treat wrote:
>
> > If by "stripped down" you mean without postgresql database support then
> > I'll grant you that, but it is no different than other any other pl
> > whose parent language require
On Mon, Apr 04, 2005 at 02:50:30PM -0400, Merlin Moncure wrote:
> > Perhaps a little delayed, but yes, I have major reservations about
> > the whole concept of spilling the lock table to disk. If you
> > implement this, I would very much like a switch to be able to turn
> > it off, somehow.
> me
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Maybe I am just dense, but the argument seems to be completely moot. PHP
is no different than Perl or Python in this case.
Perl and Python don't have "BuildPrereq: postgresql-devel" in their rpmspecs.
PHP does.
That makes per
On Mon, Apr 04, 2005 at 04:48:50PM -0400, Robert Treat wrote:
> If by "stripped down" you mean without postgresql database support then
> I'll grant you that, but it is no different than other any other pl
> whose parent language requires postgresql to be installed. If packagers
> are able to han
Robert Treat <[EMAIL PROTECTED]> writes:
> If by "stripped down" you mean without postgresql database support then
> I'll grant you that, but it is no different than other any other pl
> whose parent language requires postgresql to be installed. If packagers
> are able to handle those languages t
On Mon, 2005-04-04 at 16:17, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Monday 04 April 2005 12:01, Tom Lane wrote:
> >> Peter has pointed out that the problem of circular dependencies is a
> >> showstopper for integrating plPHP.
>
> > AFAICT Peter's claim is false. You can
I am told that the difference is that PHP gives you a choice of
statically or dynamically linked db support. By contrast, in Perl, for
example, DBD::Pg is always built dynamically (AFAIK). Your assessment
appears to be true for the (very common) case where PHP's client side
db support is dynam
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Maybe I am just dense, but the argument seems to be completely moot. PHP
> is no different than Perl or Python in this case.
Perl and Python don't have "BuildPrereq: postgresql-devel" in their rpmspecs.
PHP does.
regards, to
On Mon, Apr 04, 2005 at 07:08:11PM +0100, Simon Riggs wrote:
> IIRC there is not another major system that spills locks to disk and
> there's a big reason: performance is very poor. Other systems accept
> some limitations in order to avoid that. Oracle takes locks and holds
> them within the block
Robert Treat wrote:
On Monday 04 April 2005 12:01, Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
... If there are no license or build issues I'm in favor.
Peter has pointed out that the problem of circular dependencies is a
showstopper for integrating plPHP. The build
Robert Treat <[EMAIL PROTECTED]> writes:
> On Monday 04 April 2005 12:01, Tom Lane wrote:
>> Peter has pointed out that the problem of circular dependencies is a
>> showstopper for integrating plPHP.
> AFAICT Peter's claim is false. You can install plphp in the order of PHP,
> PostgreSQL,plPHP
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
... If there are no license or build issues I'm in favor.
Peter has pointed out that the problem of circular dependencies is a
showstopper for integrating plPHP. The build order has to be
Postgres
PHP (since its existing DB
On Monday 04 April 2005 12:01, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > ... If there are no license or build issues I'm in favor.
>
> Peter has pointed out that the problem of circular dependencies is a
> showstopper for integrating plPHP. The build order has to be
> Postg
On Thu, 2005-03-31 at 12:24 -0400, Alvaro Herrera wrote:
> On Thu, Mar 31, 2005 at 05:07:39PM +0100, Simon Riggs wrote:
> > On Sun, 2005-03-27 at 16:01 -0500, Tom Lane wrote:
> > > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > > So I think this is dead code. The attached patch removes it.
> > >
Simon Riggs <[EMAIL PROTECTED]> writes:
> DB2 even goes to great lengths to avoid this by offering additional
> locking modes of Cursor Stability (CS) - which only locks the rows
> currently being viewed or on which a cursor is currently placed. DB2
> would call locking everything Repeatable Read
> On Wed, 2005-03-30 at 18:09 -0400, Alvaro Herrera wrote:
> > I'm seeing what can I do about spilling the lock table to disk
> > I welcome comments on the ideas outlined here. If anyone sees a
> > showstopper please let me know.
>
> Perhaps a little delayed, but yes, I have major reservations ab
On Wed, 2005-03-30 at 18:09 -0400, Alvaro Herrera wrote:
> I'm seeing what can I do about spilling the lock table to disk
> I welcome comments on the ideas outlined here. If anyone sees a
> showstopper please let me know.
Perhaps a little delayed, but yes, I have major reservations about the
whol
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
... If there are no license or build issues I'm in favor.
Peter has pointed out that the problem of circular dependencies is a
showstopper for integrating plPHP. The build order has to be
Postgres
PHP (since its ex
On Mon, Apr 04, 2005 at 10:17:40PM +0800, Christopher Kings-Lynne wrote:
> >>I don't think that's a bug. You may not intend ever to cluster on that
> >>index again, and if you try it will tell you about the problem.
> >
> >
> >Except it breaks the 'cluster everything' case:
> >
> >test=# cluster;
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> ... If there are no license or build issues I'm in favor.
Peter has pointed out that the problem of circular dependencies is a
showstopper for integrating plPHP. The build order has to be
Postgres
PHP (since its existing DB support requ
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?
I have s
Hey guys,
The 'Unicode characters above 0x1' issue keeps rearing its ugly head
in the IRC channel. I propose that it be fixed, even backported...
This is John Hansen's most recent patch to fix it:
http://archives.postgresql.org/pgsql-patches/2004-11/msg00259.php
And from what I can tell it w
Honestly, I think if we're going to spend time worrying about languages
as features then we should be doing more to advertise the fact that
perl/PHP/python/ruby/etc programmers can program in the database in
their native language.
I agree with you completely.
This is something that makes PostgreSQ
"Jim Buttafuoco" <[EMAIL PROTECTED]> writes:
> Why doesn't the regression test set the timezone to GMT instead of PST. I
> believe the horology test would just work then.
... and lose any semblance of testing DST-aware behavior. Lobotomizing
the regression test isn't the answer.
(What is the a
I don't think that's a bug. You may not intend ever to cluster on that
index again, and if you try it will tell you about the problem.
Except it breaks the 'cluster everything' case:
test=# cluster;
ERROR: cannot cluster when index access method does not handle null values
HINT: You may be able
Why doesn't the regression test set the timezone to GMT instead of PST. I
believe the horology test would just work then.
Jim
-- Original Message ---
From: Tom Lane <[EMAIL PROTECTED]>
To: Michael Glaesemann <[EMAIL PROTECTED]>
Cc: PostgreSQL-development Hackers
Sent: Mon, 0
Tom Lane wrote:
Huh? DELETE hasn't got a tlist to transform ...
Yeah -- on looking closer, the patch copied and pasted a bunch of tlist
transformation code from UPDATE, but AFAICS there is no need for it.
-Neil
---(end of broadcast)---
TIP 7: don't
Some thing like instead of
static int
comparedict(const void *a, const void *b)
{
return ((DictInfo *) a)->dict_id - ((DictInfo *) b)->dict_id;
}
now used
static int
comparedict(const void *a, const void *b)
{
if ( ((DictInfo *) a)->dict_id == ((DictInfo *) b)->dict_id )
No, you can't put *.so from 8.0 to 7.4. Get 7.4 sources from cvs and compile
contrib/tsearch2.
Christopher Kings-Lynne wrote:
It's a bit tricky, since the machine I noticed it on is in production -
how would I test this on a test machine with little data?
Should I put the 8.0 tsearch2.so on my
42 matches
Mail list logo
