Re: [SQL] Function Parameters in GROUP BY clause cause errors
How amazing is that? I call it a night and come back to find that a bug has been identified and patched while I sleep. When will it appear in the binaries (I see that the release version is still 8.1.3)? I thought about trying to compile from source, but after looking at the mingw page was too intimidated by figuring out what to download to try compiling source. Best Regards, Robert Davidson -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 8:27 PM To: Davidson, Robert Cc: pgsql-sql@postgresql.org; pgsql-bugs@postgresql.org Subject: Re: [SQL] Function Parameters in GROUP BY clause cause errors I wrote: > Hmm, this seems like a plpgsql deficiency. It feels it can generate a > separate parameter symbol ($n) for each occurrence of each variable it > passes into a SQL query. But for this query to be legal, the two > instances of IntervalMinutes have to be represented by the *same* > parameter symbol (notice they are not in the regurgitated query). > It would be more efficient anyway to not generate multiple parameters > for the same value, so we oughta fix this. Patch applied to HEAD and 8.1 branches. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] OUT parameter
Tom Lane wrote: > "Owen Jacobson" <[EMAIL PROTECTED]> writes: > > I'd say there's no problem with this, PROVIDED you can ensure you'll > > never abort before completing the computation. > > Not really an issue in Postgres: we do not support pass-by-reference > parameters and are unlikely to start doing so. There isn't any way > that you can affect locals of a calling procedure before you return. Then I've misunderstood the semantics of OUT and more importantly INOUT parameters. Thanks for the correction; I'm reading Daniel Caune's notes on the docs now. -Owen ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] OUT parameter
> > "Owen Jacobson" <[EMAIL PROTECTED]> writes: > > > I'd say there's no problem with this, PROVIDED you can ensure you'll > > > never abort before completing the computation. > > > > Not really an issue in Postgres: we do not support pass-by-reference > > parameters and are unlikely to start doing so. There isn't any way > > that you can affect locals of a calling procedure before you return. > > Then I've misunderstood the semantics of OUT and more importantly INOUT > parameters. Thanks for the correction; I'm reading Daniel Caune's notes > on the docs now. > > -Owen Funny! I started that thread on OUT parameter; that's a kind of circle... :-) -- Daniel CAUNE Ubisoft Online Technology (514) 4090 2040 ext. 5418 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
