6 ms·

There's like 5 different features wants I could add like this. A columnar database engine comes to mind (slightly more work involved) and poaching a few Sqllit

by urthor 4y ago

There's like 5 different features wants I could add like this. A columnar database engine comes to mind (slightly more work involved) and poaching a few Sqllite QOL features. Ultimately Postgres is a community driven product, and people want to work on what they want the work on. I don't get angry that some kind soul hasn't volunteered their Saturday for free for me.

pbz 4y ago
Oh, absolutely; I'm just trying to raise the awareness/importance of this missing feature. Most devs that I know IRL that looked at PG had a very similar reaction to mine.
- deleted 4y ago
  [deleted]
- mixmastamyk 4y ago
  I'm receptive to the feature. But wouldn't it require locking the full table as it works? Seems like it would hurt availability of the biggest databases that would benefit most. Perhaps this is why it is thought somewhat impractical and therefore low-priority.
  - pbz 4y ago
    Depends on how the PG team decides to implement this feature. If they're OK with a virtual order (for "UI" purposes) while keeping the true order hidden then this would not require table locking (or it would be a very quick lock). If the order reflects the real / physical positioning then yes, it would probably require locking for a full table rebuild.
DangitBobby 4y ago
That's not exactly true. You can write your own patch for a feature and there's a good chance they'll decide they don't want it. It's their prerogative, but also slightly upsetting when you know they're blocking features you want. Just observe the bike shedding over a trailing commas patch [1]. 1. https://postgrespro.com/list/thread-id/1853280 https://postgrespro.com/list/thread-id/1853280
- TheP1000 4y ago
  There are lots of good reasons in that thread why the patch was declined. The patch made things more lenient which makes things less compatible (this whole thread is about ANSI SQL standards and they do matter) and changes what was an error behavior to now silently succeed. +1 to postgres devs for curating patches.
  - DangitBobby 4y ago
    I read the thread and have to disagree with "lots of good reasons". I'm pretty sure there are plenty of things in the postgres dialect that are not cross compatible with any other dialect. I agree with curating patches in general, but it's a double edged sword and inaccurate to say you can just spend your weekend to get something you care about.

by urthor 4y ago

pbz 4y ago

Oh, absolutely; I'm just trying to raise the awareness/importance of this missing feature. Most devs that I know IRL that looked at PG had a very similar reaction to mine.

deleted 4y ago
[deleted]
mixmastamyk 4y ago
I'm receptive to the feature. But wouldn't it require locking the full table as it works? Seems like it would hurt availability of the biggest databases that would benefit most. Perhaps this is why it is thought somewhat impractical and therefore low-priority.
- pbz 4y ago
  Depends on how the PG team decides to implement this feature. If they're OK with a virtual order (for "UI" purposes) while keeping the true order hidden then this would not require table locking (or it would be a very quick lock). If the order reflects the real / physical positioning then yes, it would probably require locking for a full table rebuild.

DangitBobby 4y ago

That's not exactly true. You can write your own patch for a feature and there's a good chance they'll decide they don't want it. It's their prerogative, but also slightly upsetting when you know they're blocking features you want. Just observe the bike shedding over a trailing commas patch [1]. 1. https://postgrespro.com/list/thread-id/1853280 https://postgrespro.com/list/thread-id/1853280

TheP1000 4y ago
There are lots of good reasons in that thread why the patch was declined. The patch made things more lenient which makes things less compatible (this whole thread is about ANSI SQL standards and they do matter) and changes what was an error behavior to now silently succeed. +1 to postgres devs for curating patches.
- DangitBobby 4y ago
  I read the thread and have to disagree with "lots of good reasons". I'm pretty sure there are plenty of things in the postgres dialect that are not cross compatible with any other dialect. I agree with curating patches in general, but it's a double edged sword and inaccurate to say you can just spend your weekend to get something you care about.