On Friday 29 August 2003 07:39, Ivar wrote:
> > compile-time option is not necessarily any more or less risky than a
> > runtime one. Like any option, it should just be documented and proceed
> > forward.
>
> I agree.
>
> But seems that some parts of postgre isn't designed well.
> I haven't found any db soft which supports functions/stored procedures
> which has such slow
> args limit. Postgre is comparing function speed with others, while having
> not noted limitaions.
>
> The bad thing is that there isn't any note on postgre www that there is
> such limit.
> Users start migrating from other db system, they never think that such
> simple thing
> can be turn to be such obstacle.
Hmm - if it caught you out (*) then perhaps it needs to be clearly documented.
Would you care to supply some changes to the limitations page:
http://www.postgresql.org/users-lounge/limitations.html
Maybe also to the manuals - you can find the docs for the next release in the
developer's part of the website.
You don't need to worry about formats, just some short, clear text - probably
the -docs mailing list is the best place to post it. If you don't want to
subscribe to docs just for this, then you can pass it to me if you like and
I'll pass it along.
> I have messed some weeks with postgre, I like it speed, functionality,...
> untill some days ago big
> supprise.
Well, a quick recompile and you're on your way again.
* Personally I agree with those that think if your function has 32 parameters
you need to rethink your function, but that's not the point. There are two or
three people who get caught out by this every year, so it would help if we
could let them know beforehand.
--
Richard Huxton
Archonet Ltd
