Peter Eisentraut:
On 04.06.24 18:41, Tom Lane wrote:
Relevant to this: I wonder what we think the supported macOS versions
are, anyway. AFAICS, the buildfarm only covers current (Sonoma)
and current-1 (Ventura) major versions, and only the latest minor
versions in those OS branches.
For
vinces more than the man pages ;)
Best,
WolfgangFrom 3ca5357bbdb9aae29a1785d5ca2179d6cca15cdd Mon Sep 17 00:00:00 2001
From: Wolfgang Walther
Date: Sun, 2 Jun 2024 10:46:56 +0200
Subject: [PATCH v2] Make building with clang's LTO work on macOS
When building with -flto the backend binary must keep many otherwis
Peter Eisentraut:
It's probably worth clarifying that this option is needed on macOS only
if LTO is also enabled. For standard (non-LTO) builds, the
export-dynamic behavior is already the default on macOS (otherwise
nothing in PostgreSQL would work).
Right, man page say this:
> Preserves
:00 2001
From: Wolfgang Walther
Date: Sun, 2 Jun 2024 10:46:56 +0200
Subject: [PATCH v1] Make building with clang's LTO work on macOS
When building with -flto the backend binary must keep many otherwise
unused symbols to make them available to dynamically loaded modules /
extensions. This has been
Pavel Stehule:
When you write RAISE NOTICE '%', x, then PLpgSQL parser rewrite it to
RAISE NOTICE '%', SELECT $1
There is no parser just for expressions.
That's why my suggestion in [1] already made a difference between:
SELECT var;
and
SELECT col, var FROM table, var;
So the "only
Pavel Stehule:
The session variables can be used in queries, but should be used in
PL/pgSQL expressions, and then the mandatory usage in FROM clause will
do lot of problems and unreadable code like
DO $$
BEGIN
RAISE NOTICE '% %', (SELECT x FROM x), (SELECT a,b FROM y);
END
$$
This
Pavel Stehule:
But in this case you could make variables and tables share the same
namespace, i.e. forbid creating a variable with the same name as an
already existing table.
It helps, but not on 100% - there is a search path
I think we can ignore the search_path for this
Pavel Stehule:
2. But my main argument is, it is not really safe - it solves Peter's
use case, but if I use a reverse example of Peter's case, I still have a
problem.
I can have a variable x, and then I can write query like `SELECT x FROM x`;
but if somebody creates table x(x int), then the
Tom Lane:
You'd have to commit a failing patch first to break CI for all other
developers.
No, what I'm more worried about is some change in the environment
causing the build to start failing. When that happens, it'd better
be an environment that many of us are familiar with and can test/fix.
Tom Lane:
That is not the concern here. What I think Peter is worried about,
and certainly what I'm worried about, is that a breakage in
SanityCheck comprehensively breaks all CI testing for all Postgres
developers.
You'd have to commit a failing patch first to break CI for all other
Peter Eisentraut:
On 31.03.24 15:34, walt...@technowledgy.de wrote:
I'd rather adapt one of the existing tasks, to avoid increasing CI
costs unduly.
I looked into this and I think the only task that could be changed is
the SanityCheck.
I think SanityCheck should run a simple, "average"
The need to do $subject came up in [1]. Moving this to a separate
discussion on -hackers, because there are more issues to solve than just
the LD_LIBRARY_PATH problem.
Andres Freund:
FWIW, except for one small issue, building postgres against musl works on
debian and the tests pass if I
Nazir Bilal Yavuz:
0001 & 0002: Adding code comments to explain why they have fallback
could be nice.
0003: Looks good to me.
Added some comments in the attached.
Best,
WolfgangFrom 2d271aafd96a0ea21710a06ac5236e47217c36d1 Mon Sep 17 00:00:00 2001
From: Wolfgang Walther
Date: Sat, 2
To build on NixOS/nixpkgs I came up with a few small patches to
meson.build. All of this works fine with Autoconf/Make already.From 24ae72b9b0adc578c6729eff59c9038e6b4ac517 Mon Sep 17 00:00:00 2001
From: Wolfgang Walther
Date: Sat, 2 Mar 2024 17:18:38 +0100
Subject: [PATCH 1/3] Fallback to uuid
Robert Haas:
Scratch my previous suggestion. A new, less fuzyy definition would be:
Ownership is not a privilege itself and as such not inheritable.
[...]
If I'm understanding correctly, this would amount to a major
redefinition of what it means to inherit privileges, and I think the
chances of
Robert Haas:
I don't think we're going to be very happy if we redefine inheriting
the privileges of another role to mean inheriting only some of them.
That seems pretty counterintuitive to me. I also think that this
particular definition is pretty fuzzy.
Scratch my previous suggestion. A new,
Robert Haas:
This shows that if rhaas (or whoever) performs DML on a table owned by
pg_read_all_settings, he might trigger arbitrary code written by alice
to run under his own user ID. Now, that hazard would exist anyway for
tables owned by alice, but now it also exists for any tables owned by
James Coleman:
As I was reading through the email chain I had this thought: could you
get the same benefit (or 90% of it anyway) by instead allowing the
creation of a uniqueness constraint that contains more columns than
the index backing it? So long as the index backing it still guaranteed
the
James Coleman:
So the broader point I'm trying to make is that, as I understand it,
indexes backing foreign key constraints is an implementation detail.
The SQL standard details the behavior of foreign key constraints
regardless of implementation details like a backing index. That means
that the
Peter Geoghegan:
On Sun, Sep 25, 2022 at 8:55 AM Wolfgang Walther
wrote:
The attached patch adds a DO RETURN clause to be able to do this:
INSERT INTO x (id) VALUES (1)
ON CONFLICT DO RETURN
RETURNING created_at;
Much simpler. This will either insert or do nothing - but in both cases
James Coleman:
If we have a declared constraint on x,y where x is unique based on an
index including on x I do not think we should have that fk constraint
work differently than a constraint on x,y where there is a unique
index on x,y. That would seem to be incredibly confusing behavior
(even if
)
ON CONFLICT DO RETURN
RETURNING created_at;
Much simpler. This will either insert or do nothing - but in both cases
return a row.
Thoughts?
Best
Wolfgang>From 83a0031ed2ded46cbf6fd130bd76680267db7a5e Mon Sep 17 00:00:00 2001
From: Wolfgang Walther
Date: Sun, 25 Sep 2022 16:20:44 +0200
Subj
Robert Haas:
Well, maybe. Suppose that role A has been granted pg_read_all_settings
WITH INHERIT TRUE, SET TRUE and role B has been granted
pg_read_all_settings WITH INHERIT TRUE, SET FALSE. A can create a
table owned by pg_read_all_settings. If A does that, then B can now
create a trigger on
James Coleman:
If I'm following properly this sounds like an overengineered EAV
schema, and neither of those things inspires me to think "this is a
use case I want to support".
That being said, I know that sometimes examples that have been
abstracted enough to share aren't always the best, so
Robert Haas:
I think to change the owner of an object from role A to role B, you just
need a different "privilege" on that role B to "use" the role that way,
which is distinct from INHERIT or SET ROLE "privileges".
It's not distinct, though, because if you can transfer ownership of a
table to
Robert Haas:
Fairly obviously, my thinking here is biased by having written the
patch to allow restricting SET ROLE. If alice can neither inherit
bob's privileges nor SET ROLE bob, she had better not be able to
create objects owned by bob, because otherwise she can make a table,
add an
Kaiting Chen:
I'd like to propose a change to PostgreSQL to allow the creation of a foreign
key constraint referencing a superset of uniquely constrained columns.
+1
Tom Lane:
TBH, I think this is a fundamentally bad idea and should be rejected
outright. It fuzzes the semantics of the FK
Robert Haas:
Beginning in
e3ce2de09d814f8770b2e3b3c152b7671bcdb83f, the inheritance behavior of
role-grants can be overridden for individual grants, so that some
grants are inherited and others are not.
That's a great thing to have!
However, there is no similar
facility for controlling
Dean Rasheed:
That is also the main reason I preferred naming it "security_invoker" -
it is consistent with other databases and eases transition from such
systems.
[...]
For my part, I find myself more and more convinced that
"security_invoker" is the right name, because it matches the
Hi,
currently a failed cast throws an error. It would be useful to have a
way to get a default value instead.
T-SQL has try_cast [1]
Oracle has CAST(... AS .. DEFAULT ... ON CONVERSION ERROR) [2]
The DEFAULT ... ON CONVERSION ERROR syntax seems like it could be
implemented in PostgreSQL.
osumi.takami...@fujitsu.com:
* I'm a little bit concerned about the semantics of changing the
tgdeferrable/tginitdeferred properties of an existing trigger. If there are
trigger
events pending, and the trigger is redefined in such a way that those events
should already have been fired, what
Peter Eisentraut:
On 2019-12-31 00:07, Vik Fearing wrote:
One thing I notice is that the joined columns are still accessible from
their respective table names when they should not be per spec. That
might be one of those "silly restrictions" that we choose to ignore, but
it should probably be
Tom Lane:
We don't generally act that way in other ALTER commands and I don't see
a strong argument to start doing so here. [...]
In short, I'm inclined to argue that this variant of ALTER TABLE
should replace *all* the fields of the constraint with the same
properties it'd have if you'd
33 matches
Mail list logo
