Re: Just for fun: Postgres 20?
And nobody is asking about all the "missing" versions like in a big red superstitious database. Am Montag, 10. Februar 2020, 00:45:02 MEZ hat tsunakawa.ta...@fujitsu.com Folgendes geschrieben: From: Jose Luis Tallon > Musing some other date-related things I stumbled upon the thought > that naming the upcoming release PostgreSQL 20 might be preferrable to > the current/expected "PostgreSQL 13". +1 Users can easily know how old/new the release is that they are using. Regards Takayuki Tsunakawa
Re: Just for fun: Postgres 20?
Please don't take personal but when you open a discussion like that on number 13 then you are doing something very christian centric and forget the rest of the world. As there are more cultural spheres than the christian one on this planet can you please elaborate the next number which is acceptable (PostgreSQL) world wide? May I assist you a little bit? The number 4 in japanese and chinese are spoken the same way as the word for death. 14 is spoken as ten-four. That'd a reason to skip PostgreSQL ten-death a.k.a. 14, too, isn't it? You don't want a PG death version, do you? By the way: In Japan or in jewish tradition 13 is a lucky number (see Freitag, der 13. – Wikipedia, sorry, german only). Why do you want to skip a lucky number? Do you prefer PostgreSQL ju-san because that's a lucky number instead of PostgreSQL 13 because that's a unlucky one? Am Montag, 25. Mai 2020, 11:04:53 MESZ hat Jiří Fejfar Folgendes geschrieben: On 15.02.2020 1:18, Tom Lane wrote: > The idea that 13 is unlucky is Western, and maybe even only common in > English-speaking countries. Number 13 (especially Friday 13) is also considered unlucky In Czech republic (central Europe, Slavic language). -- Jiří.
Re: Is there any chance to get some kind of a result set sifting mechanism in Postgres?
Hi, do I interpret your idea correctly: You want some sort of ordering without ordering? Kind regardsWW Am Montag, 13. Mai 2024 um 10:40:38 MESZ hat aa Folgendes geschrieben: Hello Everyone! Is there any chance to get some kind of a result set sifting mechanism in Postgres? What I am looking for is a way to get for example: "nulls last" in a result set, without having to call "order by" or having to use UNION ALL, and if possible to get this in a single result set pass. Something on this line: SELECT a, b, c FROM my_table WHERE a nulls last OFFSET 0 LIMIT 25 I don't want to use order by or union all because these are time consuming operations, especially on large data sets and when comparations are done on dynamic values (eg: geolocation distances in between a mobile and a static location) What I would expect from such a feature, will be speeds comparable with non sorted selects, while getting a very rudimentary ordering. A use case for such a mechanism will be the implementation of QUICK relevant search results for a search engine. I'm not familiar with how Postgres logic handles simple select queries, but the way I would envision a result set sifting logic, would be to collect the result set, in 2 separate lists, based on the sifting condition, and then concatenate these 2 lists and return the result, when the pagination requests conditions are met. Any idea if such a functionality is feasible ? Thank you. PS: if ever implemented, the sifting mechanism could be extended to accommodate any type of thresholds, not just null values.
