In MSSQL Server part of the plan match is the various session/connection options, if they are different there are different plans cached.
I believe the plan data structure PG is intimately tied to process space memory addresses since it was never thought to share between them and can even contain executable code that was generated.
This makes it difficult to share between processes without a heavy redesign but would be a good change IMO.
This is very good to know because it means this exclusion constraint workaround is a better approach over using a SQL hash function and a btree if you want to enforce uniqueness on values too long for a btree index.
Not sure if that’s what you mean but we have apps where all you need to deploy them to Kubernetes is run “cue cmd deploy”.
> The problem is, once you have to wrap CUE, the loss of flexibility within a special-purpose language like CUE is enough for people to ask why not just bother writing the scripts in a general purpose language with better ecosystem support.
cue cmd is nice but it’s not the reason to use CUE. The data parts are. I would still use if I had to use “cue export” to get the data out of it with a bit of shell.
So cue cmd also built the image, authenticated to a private registry, pushed the image, authenticated to the private Kubernetes cluster, and ran kubectl apply?
No, that’s why I said deploy. All it does is run kubectl apply and kubectl rollout status.
Only those are directly tied to the data in CUE. there’s not much advantage to running other commands with it. You can run arbitrary processes with cue cmd though.
Yeah but that's kinda my point. OK you can write policy to control the Kubernetes configuration with CUE. What about policy to control the Dockerfile, let alone the policy to control the cloud infrastructure? No? So the Security folk writing policy need to learn two languages - one for general-purpose policy, plus CUE specifically for Kubernetes manifests? Why not write the policy for Kubernetes manifests in the general-purpose language they're using for the rest of the policy? And so on and so forth, which make CUE's value proposition dubious in the enterprise.
I had the same thought about the idea that Safari is “behind”. My hypothesis is that features only “exist” to people if they are implemented in Chrome. If a feature exists in WebKit but not in Chrome, nobody talks about it.
If a web browser doesn't support an API, they're essentially saying: If you want to do this, you have to make people install a native app. And the websites reponse is: Fine, I'll make people install a native app: Chrome.
Me too! If you want to do cool things with a web browser, you sure can't do it with Safari. And how many times have you been told you need to install a specific app to access a specific service? For me it's too many to count.
One possible reason is that the planner configuration can be different per connection, so the plans might not transfer
reply