Re: any way for ORDER BY x to imply NULLS FIRST in 8.3?

Scott Marlowe wrote:
> On Nov 9, 2007 5:17 AM, rihad <rihad(at)mail(dot)ru> wrote:
>>> Em Wednesday 07 November 2007 13:54:32 rihad escreveu:
>>>> May I, as an outsider, comment? :) I really think of ASC NULLS FIRST
>>>> (and DESC NULLS LAST) as the way to go. Imagine a last_login column that
>>>> sorts users that have not logged in as the most recently logged in,
>>>> which is not very intuitive. I vote for sort_nulls_first defaulting to
>>>> false in order not to break bc.
>>> But then, when ordering by login date, you should use COALESCE and infinity
>>> for them
>>> (http://www.postgresql.org/docs/8.2/interactive/datatype-datetime.html).
>> It's not an easy thing to do with for example Propel 1.2 ORM (written in
>> PHP):
>>
>> $criteria->addDescendingOrderByColumn(myPeer::LAST_LOGIN); // no place
>> to shove database-specific attributes in.
>
> Why not create an updatable view that orders the way you want it to?
>
>

I've already thought about this, but... there aren't yet truly updatable
views in PostgreSQL, but rather query rewriting a.k.a.
text-substitution; 1) it isn't of paramount importance in my current
case. It just wouldn't be bad to set sort_nulls_first=true, if it existed.

If you wan't to know the full story, prepare for some OT :-)
Because of the way Symfony/Propel does its "object hydration" has
already forced me to write views in postgres to minimize the amount of
data fetched: otherwise Propel is happy to fetch full-records from db,
and all its FK-related objects, too (the lazyLoad misfeature is a
two-sided gun: it pretends it fetches only this many columns for each
row, but if you later access further columns each one will cost you a
separate database hit), all of which is unacceptable for e.g. displaying
a HTML table of N items with pagination etc. Symfony/Propel is also
quite happy to hydrate the full object from db just for save()'ing it
back to db right away (on a form POST for a record update, for example),
which makes my brain hurt, so I went to the trouble of avoiding the
pre-hydration, too. This all resulted in much effort not directly
related to the business logic of my app, but rather on overriding
Symfony's way of doing everyday web-programming tasks (like form
validation, results listing, editing). Now I don't really want to work
around further design inefficiencies of Symfony/Propel by trying
updatable views. Really frustrating. Easier to just forgo any
web-framework and write quality code yourself instead, like
phpclasses.org's Manuel Lemos once said in his article... That said,
Symfony 1.1-DEV/Doctrine begin to look promising.