e it, you won't
> need any logic changes in your app code (Java or whatever), e.g.
>
> *select where x=:x ..(select .. where . y=:y)
> *
> Becomes
>
> *select myfunction(:x, :y)
> *
>
> On Mon, Nov 16, 2009 at 2:45 PM, Eddy Escardo-Raffo
This is incredibly helpful, Kenneth. I didn't know about the SETOF syntax at
all. This could help minimize the amount of refactoring I need to do.
Thanks!
Eddy
On Mon, Nov 16, 2009 at 12:55 PM, Kenneth Marshall wrote:
> On Mon, Nov 16, 2009 at 12:45:46PM -0800, Eddy Escardo-Raf
Yeah this kind of thing would probably work. Doing this in java with
separate queries would be easy to code but require multiple round trips.
Doing it as a stored procedure would be nicer but I'd have to think a little
more about how to refactor the java code around the query to make this
happen. T
ners (including the postgres planner)
don't do this kind of contingency planning :)
Thanks!
Eddy
On Sun, Nov 15, 2009 at 5:46 PM, Eddy Escardo-Raffo wrote:
> I was using VALUES in my examples to more closely mirror the results of a
> sub-select (I abstracted everything else away and noticed tha
y integer
literals? If so, I think it's ok, because it seems like statements C or D
will work well enough when the location distribution is realistic, but I'd
like to be educated for the future :)
Thanks again!
Eddy
On Sun, Nov 15, 2009 at 3:59 PM, Eddy Escardo-Raffo wrote:
> Thanks,
e drop significantly.
(even more detail: my queries also limit results to 10 approx, so DB quickly
found 10 rows that match location -1, but it took a while to discover there
weren't more than 2 rows with the other value).
Thanks!
Eddy
On Sun, Nov 15, 2009 at 3:33 PM, Tom Lane wrote:
>
Hi, everyone.
Between postres docs, forum posts, previous similar questions answered and
random blogs, I've read as much as I could about why others have had similar
problems in the past before turning to you guys for help, so I really hope
this is not some completely obvious oversight on my part
