Re: Overriding natural order of query results for a subset

From: Laura Smith <n5d9xq3ti233xiyif2vp(at)protonmail(dot)ch>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Nolan <htfoot(at)gmail(dot)com>, postgre <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Overriding natural order of query results for a subset
Date: 2021-05-29 19:04:08
Message-ID: OaTqY8XwhM-4R_6fR9LSaysfFTU0MpExBlnp_AiJFZ8ujFAHdSbomM7PaVvQRB2_c6B-DRdclSEWgx3654yDMzO90X-enWFYPgghyvMP0n4=@protonmail.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 29 May 2021 17:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Michael Nolan htfoot(at)gmail(dot)com writes:
>
> > You probably need some kind order by case when .... else .... end clause,
> > where the else clause deals with the non-VIPs, probably negating the need
> > for a nulls last clause.
>
> The idiomatic way to do this, assuming that you create an "is_vip bool"
> field or some other way to identify VIPs accurately, is
>
> ORDER BY is_vip DESC, last_name, first_name
>
> relying on the fact that bool TRUE > bool FALSE.
>
> regards, tom lane

Thanks tom !

I think yours combined with Adrian's "DEFAULT of 0" is likely to be the winner.

Doing some experimenting, it gives me three options:
- Leave field as default = default name alphabetic
- Add VIPs with same integer = VIPs at the top, ordered alphabetically
- Add VIPs with differing integers = VIPs ordered by protocol

Thanks all.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dean Gibson (DB Administrator) 2021-05-29 19:59:47 Re: AWS forcing PG upgrade from v9.6 a disaster
Previous Message Tom Lane 2021-05-29 16:55:54 Re: Overriding natural order of query results for a subset