David Olbersen wrote:
> *sigh* I'd rather have pilot error than having to wait for a patch :)
Hmmm, that doesn't look right in retrospect. What I meant to say was
THANK YOU TOM!
--
David Olbersen
iGuard Engineer
St. Bernard Software
15015 Avenue of Sciences
San Diego, CA 92127
x2152
-
Tom Lane wrote:
> Hate to tell you this, but it's just pilot error. You've got comments
> like these embedded in the plpgsql function:
>
> ELSIF cat = ''none'' THEN
> -- none,none = don't show the languages, or categories
> (whaaat?) FOR result IN
>
>
Tom Lane wrote:
> Hmm ... plpgsql had some string-length issues as recently as 7.2.2, but
> I don't know of any problems since then. Could you submit a *complete*
> test case, rather than making us guess the details?
Sure. I didn't want to dump a huge email to have somebody say "Addressed in 7.3
On Wednesday 17 March 2004 00:47, David Olbersen wrote:
>
> Here's the "clean" code that doesn't work:
>
> FOR result IN
> SELECT
> initcap( c.name ) AS category,
> initcap( l.language ) AS language,
>
"David Olbersen" <[EMAIL PROTECTED]> writes:
> I was minding my business, writing a nice long pl/pgsql function and all was well. I
> tried creating the function (using \i ) and started getting
> funny errors.
> I figured out eventually that the problem seems due to line length in a construct
>
