Hi Kevin, Thanks for your repply. I can't be sure whether the two functions have the same X value, and I don't want them twice, that's why I was using UNION, instead of UNION ALL (which is much faster even...).
But what you said make some sense. Do you think if use first a UNION ALL and then in the outer query (when I order by q.t) I use DISTINCT may work? I think I will try it out. Thanks again for the help. Rodrigo Sperb Kevin Neufeld wrote: > > Are you sure you want to use "UNION" and not "UNION ALL"? The former > will remove duplicates, the latter does not. It's conceivable that when > UNIONed, the three SELECT st_X clauses will return a single value. > Collected and put through ST_LineFromMultiPoint would probably result in > a single point line (depending on which version of PostGIS you are using > - the newer versions will ERROR with "geometry requires more points"). > > Hope that helps, > Kevin > > rodrigosperb wrote: >> Hello, >> >> I have a bit of a problem that is sort of driving me crazy. I need to >> perform an "addition of two (mathematical) functions". I represent them >> as >> linestrings in my solution, and it is part of another bigger function. >> The >> code is as follows: >> >> ...header... >> SELECT st_LineFromMultiPoint(st_Collect(st_MakePoint(xy.t,xy.at))) >> FROM (SELECT q.t, dr_delay_value($1,q.t) + >> dr_delay_value($3,dr_delay_value($1,q.t)) AS at >> FROM (SELECT st_X(st_PointN($1,n)) AS t >> FROM generate_series(1,st_NumPoints($1)) AS h(n) >> UNION >> SELECT st_X(st_PointN($2,n)) AS t >> FROM generate_series(1,st_NumPoints($2)) AS h(n) >> UNION >> SELECT st_Xmax($1) AS t >> ) AS q ORDER BY q.t) AS xy >> ...bottom... >> dr_delay_value() is simply a look-up function that takes the Y value for >> a >> certain X. >> >> The thing is that eventually this fuction is failing on returning more >> specifically a 2-points linestring (that sould) and returns only a single >> point one. Now, I have prepared a "wrapper" PL/Pgsql function to keep >> track >> of what is passed to that function (perhaps that was the reason for the >> error. With that I'm pretty much sure that the arguments passed are fine, >> and still get the same error... Strangely, with my wrapper function >> keeping >> track of the arguments passed to the function I was able to try out to >> run >> the same request (that inside of the bigger function fails) separately, >> and >> guess what? is simply works!! >> >> I hope anyone may have a clue of what is going on. That's a very strange >> behavior, I would say. >> >> Regards, >> >> Rodrigo Sperb >> > _______________________________________________ > postgis-users mailing list > [email protected] > http://postgis.refractions.net/mailman/listinfo/postgis-users > > -- View this message in context: http://old.nabble.com/Is-that-possible-a-function-to-behave-differently-inside-and-outside-another-main-function-code--tp26251542p26255804.html Sent from the PostGIS - User mailing list archive at Nabble.com. _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
