> 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.
I have messed some weeks with postgre, I like it speed, functionality,...
untill some days ago big
supprise.
"Jonathan Bartlett" <johnnyb@eskimo.com> wrote in message
news:Pine.GSU.4.44.0308281507350.14633-100000@eskimo.com...
> Also, it should be noted that an untested or welltested compile option is
> just as stable as an untested or welltested runtime option. Using a
> 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.
>
> Jon
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
