> 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 :/
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?
> 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.
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.
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.
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.
20 comments
[ 3.1 ms ] story [ 58.7 ms ] threadI'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 :/
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.
In C99
but on systems which emulate bool with, e.g., an 8-bit unsigned char thenTIL 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
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.
Josh Berkus discusses this here:
http://www.databasesoup.com/2016/05/changing-postgresql-vers...
(disclaimer: my employer (but open source))
DBeaver is another great alternative.