20 comments

[ 3.1 ms ] story [ 58.7 ms ] thread
> Spinlock fixes and support for Motorola 68K and 88K architectures

I'm astounded that they support those architectures

> I'm astounded that they support those architectures

I work on PG, and I'm regularly astounded too...

As long as the compilers are new enough, the burden isn't too high though. Previously it prevented us from using atomics for some concurrency optimized things, but now we've an atomics implementation that, at compile time, falls back to a spinlock backed atomics implementation. Slightly complicated by the fact that we don't even have a hard dep on a spinlock implementation, falling back to semaphores :)

Ah. Fun.

But seriously, the thing that hurts more is that we only require a C89 compiler :/

> But seriously, the thing that hurts more is that we only require a C89 compiler :/

Indeed. For a glimpse for the non-PG-hackers (like me), there's an ongoing attempt discussed in the PG-hackers mailing list to use stdbool.h.

That can be tricky because you can't emulate the semantics of the C99 bool type.

In C99

  (bool)256 == 1
but on systems which emulate bool with, e.g., an 8-bit unsigned char then

  (bool)256 == 0
Another problem is that the bool provided by stdbool.h is 4 bytes on some platforms, which breaks PostgreSQL all over the place.
What uses those these days?
From the release notes: >Fix sample INSTR() functions used to help transition from Oracle(r) PL/SQL to PostgreSQL PL/pgSQL to correctly match Oracle functional behavior

TIL PL/pgSQL exists so I googled it. In the page for porting from Oracle PL/SQL:

>Instead of packages, use schemas to organize your functions into groups.

Does anyone know if there are plans to introduce packages in Postgres? Doesn't putting function in different schemas mean you have to grant select/update permissions to the schemas that talk to other schemas?

*edit:formatting

> Doesn't putting function in different schemas mean you have to grant select/update permissions to the schemas that talk to other schemas?

In Pg, schemas don't talk to schemas. When a function is run, it runs with the privilege level of either the user that called it, or the user that defined it.

I'd like to see updated versions of PL/v8 ship. The situation with building v8 is so bad ( https://github.com/plv8/plv8/issues/251#issuecomment-3645410... ), that almost the entire cloud infrastructure (AWS, Heroku, Docker) is stuck with an ancient version of PL/v8.
AWS only goes up to 9.6.5 - I don't know that PL/v8 is the reason for that.
The solution is to fire whoever convinced you that javascript belongs in your database.
Pl/v8 is at least safer than PL/Python due to being properly sandboxed ;-)
Hmm I'm a bit confused. Why did they decide to do this ?
Largely because the previous version numbering was sometimes confusing for the opposite reason: Postgres "major" releases were sometimes interpreted as point releases. For example, 9.1 to 9.2 was major version jump. While that was understood by those who already understood the versioning scheme, it was often confusing to those outside the community.

Josh Berkus discusses this here:

http://www.databasesoup.com/2016/05/changing-postgresql-vers...

It's a shame that Postgres 10 still ships with the abomination that is pgAdmin 4. You don't have a lot of other choices either (the pgAdmin 3 LTS version still throws error left and right when connection to a postgres 10 DB)
This is package specific. pgAdmin is a separate project. There are other tools out there (there is a recent Show HN thread for a macOS client and the comments include other tools), though to be honest I use psql almost exclusively, so I'm not one to ask for recommendations.
Try OmniDB perhaps?

(disclaimer: my employer (but open source))

dbeaver is free & can connect to multiple db types. (have used it with postgres as i agree that pgAdmin 4 is v. bad interface)
Agreed. Tried pgAdmin 4, and it's not a happy user experience. Reverting back to pgAdmin 3 gives errors, depending on what you attempt to do. I have Navicat, and some features are good, yet some are frustrating. Postgres needs a "gold standard" ux tool. Maybe there is one, but I have not used it before.