Re: Overriding natural order of query results for a subset - Mailing list pgsql-general

From Laura Smith
Subject Re: Overriding natural order of query results for a subset
Date
Msg-id OaTqY8XwhM-4R_6fR9LSaysfFTU0MpExBlnp_AiJFZ8ujFAHdSbomM7PaVvQRB2_c6B-DRdclSEWgx3654yDMzO90X-enWFYPgghyvMP0n4=@protonmail.ch
Whole thread Raw
In response to Re: Overriding natural order of query results for a subset  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 29 May 2021 17:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Michael Nolan htfoot@gmail.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.




pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Overriding natural order of query results for a subset
Next
From: Michael Lewis
Date:
Subject: Re: AWS forcing PG upgrade from v9.6 a disaster