Fun fact: A query like this will, once in a blue moon, return more than limit (here 1) row, since the inner query is executed multiple times and returns different ids, which is surprising for a lot of people. If your code does not expect that, it may cause problems. (The article seems to, since it uses a list and iteration to handle the result.)

  delete from task
  where task_id in
  ( select task_id
    from task
    order by random() -- use tablesample for better performance
    for update
    skip locked
    limit 1
  )
  returning task_id, task_type, params::jsonb as params 

Also, if your tasks take a long time, it will create long-running transactions, which may cause dead tuple problems. If you need to avoid that, you can mark the task as "running" in a short-lived transaction and delete it in another. It becomes more complicated then, since you need to handle the case that your application dies while it has taken a task.

It's also not visible in the directory tree on the left.

(Oddly enough another comment mentioned this already and is voted dead. Why?)

It generally seems to be a thing in trading: https://databento.com/pcaps

There is also this (though this page does not specify what pcap means): https://www.lseg.com/en/data-analytics/market-data/data-feed...

The free version of ChatGPT is 4o now, isn't it? So maybe Gemini has not gotten worse, but the free alternatives are now better? When I compare ChatGPT-4o with Gemini-Advanced (wich is 1.5 Pro, I believe) the latter is just so much worse.

Comments URL: https://news.ycombinator.com/item?id=40987812

Points: 2

# Comments: 0

OpenAPI is another example. There are threads on hacker news about generating code from OpenAPI specs. These always seem to say "oh, yes don't use tool X, use tool Y it does not have that problem, although it also doesn't support Z". The consensus seems to be to not generate code from an OpenAPI specification but to just use it as documentation, since all generators are more or less broken. Contrast that with for example JAXB (which is not an exact replacement I know), which has been battle tested for years.

Compare that to XML where we have a plethora of established tools (Woodstoxx, JAXB, etc.).

What I have trouble to understand, which everybody else just seems to accept as obvious, is why one would take on these problems? Is JSON Schema more powerful than XML Schema? Does the use of JSON have advantages over using XML? When we are talking about a client program calling a server API with JSON/XML, why do we care about the format of data exchanged? What advantages does JSON have in this case in contrast to XML (or for that matter a binary format like Protocol Buffers)? Isn't this the most boring part of the application, which you would want to just get out of the way and work? What are the advantages of JSON over XML that would lead me to deal with the problems of evolving specifications and unreliable tooling?

(And just to repeat, since everybody seems to have a different opinion about this than me, I must be missing something and really would like to learn what!)

"This report seems entirely correct and it hurts in my soul."

and the blog:

"[...] shipping a heap overflow in code installed in over twenty billion instances is not an experience I would recommend."

Harsh to have to bear that responsibility for so little reward.