Re: [HACKERS] [GENERAL] How do I bump a row to the front of sort efficiently
On Mon, Feb 2, 2015 at 1:16 AM, Sam Saffron sam.saff...@gmail.com wrote: However, the contortions on the above query make it very un-ORM friendly as I would need to define a view for it but would have no clean way to pass limits and offsets in. This is why ORMs are bad. They make hard problems *much* harder, and the only benefit is that they maybe make easy problems a little quicker. The cost/savings is *heavily* skewed toward the cost, since there's no upper bound on the cost and there is a pretty small lower bound on the savings. Micro-ORMs tend to do a better job of not shielding you from (or rather, getting in the way of) the SQL while still providing some good result-to-object translation. Whether even that is necessary depends on your language, though. (For example, in Python, psycopg2 has a built in way of spitting out namedtuples, which means you get result-to-object translation out of the box. That makes even a micro-ORM pretty unnecessary. On the other hand, a micro-ORM that does this well without blocking you from the SQL, such as PetaPOCO, is a boon in .NET.) If you can, your best bet would probably be to find a way to get your ORM to execute raw SQL (with good parametrization to prevent injection attacks) and be done with it. It took me way too much experience fighting with an ORM on complicated queries to realize that.
Re: [HACKERS] [GENERAL] How do I bump a row to the front of sort efficiently
On Tue, Feb 3, 2015 at 9:33 PM, BladeOfLight16 bladeofligh...@gmail.com wrote: This is why ORMs are bad. They make hard problems *much* harder, and the only benefit is that they maybe make easy problems a little quicker. The cost/savings is *heavily* skewed toward the cost, since there's no upper bound on the cost and there is a pretty small lower bound on the savings. Micro-ORMs tend to do a better job of not shielding you from (or rather, getting in the way of) the SQL while still providing some good result-to-object translation. Whether even that is necessary depends on your language, though. (For example, in Python, psycopg2 has a built in way of spitting out namedtuples, which means you get result-to-object translation out of the box. That makes even a micro-ORM pretty unnecessary. On the other hand, a micro-ORM that does this well without blocking you from the SQL, such as PetaPOCO, is a boon in .NET.) If you can, your best bet would probably be to find a way to get your ORM to execute raw SQL (with good parametrization to prevent injection attacks) and be done with it. It took me way too much experience fighting with an ORM on complicated queries to realize that. Er, *pretty small upper bound on the savings.
Re: [HACKERS] [GENERAL] postgres FDW cost estimation options unrecognized in 9.3-beta1
On Fri, Jul 26, 2013 at 6:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: snip I think we could do with both more documentation, and better error messages for these cases. In the SET-where-you-should-use-ADD case, perhaps ERROR: option use_remote_estimate has not been set HINT: Use ADD not SET to define an option that wasn't already set. In the ADD-where-you-should-use-SET case, perhaps ERROR: option use_remote_estimate is already set HINT: Use SET not ADD to change an option's value. snip Thoughts, better wordings? Since SET is more or less a keyword in this context and there's already not some obvious things about it, it might be better to avoid using it with a slightly different meaning in the error messages. Maybe defined would be clearer? That would be consistent with your usage of define in the first error message as well. ERROR: option use_remote_estimate has not been defined HINT: Use ADD not SET to define an option that wasn't already defined. ERROR: option use_remote_estimate is already defined HINT: Use SET not ADD to change an option's value. Just a thought.
