On Tue, Jan 07, 2025 at 06:52:33PM -0800, Noah Misch wrote:
> It's more optimal to write '0'::bigint. That generates a CONST node, whereas
> 0::bigint generates a FUNCEXPR calling the cast function. No other concerns.
Makes sense, done this way.
--
Michael
signature.asc
Description: PGP signat
On Wed, Jan 08, 2025 at 11:32:00AM +0900, Michael Paquier wrote:
> On Mon, Jan 06, 2025 at 11:04:28AM -0800, Noah Misch wrote:
> > Per postgr.es/m/3489827.1618411...@sss.pgh.pa.us and
> > postgr.es/m/1471865.1734212...@sss.pgh.pa.us one requirement for migrating
> > to
> > SQL-standard function bo
On Mon, Jan 06, 2025 at 11:04:28AM -0800, Noah Misch wrote:
> Per postgr.es/m/3489827.1618411...@sss.pgh.pa.us and
> postgr.es/m/1471865.1734212...@sss.pgh.pa.us one requirement for migrating to
> SQL-standard function bodies is removing these inexact-match function and
> operator calls. Here, one
On Tue, Nov 12, 2024 at 05:30:30PM +0900, Michael Paquier wrote:
> 0004 for pg_freespace is fine regarding that for example as we have
> calls of pg_freespace(regclass) in its sql/. I've applied it to begin
> with something.
That commit (3f323eb) contains a generate_series(int, bigint) call. Fol
I happened to notice that there's more that we can do to harden
contrib modules: the transform modules for hstore and ltree
currently have disclaimers about having to install them in the
same schema as the underlying modules. AFAICS that can be
fixed trivially now, by using the @extschema:name@ me
I wrote:
> I reviewed and pushed these. Let's not forget that the pageinspect
> one is still pending, though. We were waiting on Tomas' fix, which
> is now pushed at 957ba9ff1, so I suppose it needs a rebase.
Actually ... that one's quite trivial, so I went ahead and pushed it.
The submitted pa
I wrote:
> Here's the remaining two patches in the current set. This is just
> to pacify the cfbot: I've not done anything to them, just verified
> that they still apply and pass regression.
I reviewed and pushed these. Let's not forget that the pageinspect
one is still pending, though. We were
Here's the remaining two patches in the current set. This is just
to pacify the cfbot: I've not done anything to them, just verified
that they still apply and pass regression.
regards, tom lane
>From 9c5235cd123eeb55b95b8bfd281dfcc37df197c5 Mon Sep 17 00:00:00 2001
From:
I wrote:
> I see that the cfbot is unhappy because it doesn't understand
> that some of the patches have been applied already. I am going
> to go ahead and get the earthdistance one done, because we have
> a live problem report about that [1]. I'll rebase and repost
> the remainder afterwards.
P
Michael Paquier writes:
> Doing that step-by-step is better than nothing, hence limiting the use
> of named parameters for only the functions whose body is rewritten is
> fine by me, as a first step, as long as the names are used rather the
> dollar parameter numbers. I'd suggest to do take the b
On Wed, Nov 13, 2024 at 09:15:08AM +0100, Ronan Dunklau wrote:
> Ok, please find attached a new complete patch series including tests for the
> uncovered functions. Tests pass both before and after the move to SQL-body
> functions.
In 0001 for the tests of contrib/xml2/, you have forgotten to up
On Wed, Nov 13, 2024 at 09:39:06AM +0100, Peter Eisentraut wrote:
> By the way, if we're going to touch all these extension script files to make
> them more modern SQL-like, we could also use named parameters more.
Sounds like a good idea to do. Thanks for the suggestion.
--
Michael
signature.a
Le mardi 12 novembre 2024, 09:30:30 heure normale d’Europe centrale Michael
Paquier a écrit :
> On Thu, Nov 07, 2024 at 10:06:37AM +0900, Michael Paquier wrote:
> > Good point. Checking all these contrib updates one-by-one is an ant's
> > work, but I'll see if I can get at least some of them done
On 13.11.24 09:15, Ronan Dunklau wrote:
Le mardi 12 novembre 2024, 09:30:30 heure normale d’Europe centrale Michael
Paquier a écrit :
On Thu, Nov 07, 2024 at 10:06:37AM +0900, Michael Paquier wrote:
Good point. Checking all these contrib updates one-by-one is an ant's
work, but I'll see if I c
On Thu, Nov 07, 2024 at 10:06:37AM +0900, Michael Paquier wrote:
> Good point. Checking all these contrib updates one-by-one is an ant's
> work, but I'll see if I can get at least some of them done on HEAD.
I've begun looking at that a bit, and there are a couple of things
that we could do better
On Wed, Nov 06, 2024 at 10:51:29AM +0100, Ronan Dunklau wrote:
> For most of them I agree, but one side effect of the current implementation
> is
> that we have a bug when pg_upgrad'ing if earthdistance is installed:
> https://www.postgresql.org/message-id/flat/
> 152106914669.1223.5104148605998
Le mercredi 6 novembre 2024, 06:52:16 heure normale d’Europe centrale Michael
Paquier a écrit :
> On Tue, Nov 05, 2024 at 08:05:16PM -0500, Tom Lane wrote:
> > No, I don't think so. For one thing, it would not help existing
> > installations unless they issue "ALTER EXTENSION UPDATE", which
> > p
On Tue, Nov 05, 2024 at 08:05:16PM -0500, Tom Lane wrote:
> No, I don't think so. For one thing, it would not help existing
> installations unless they issue "ALTER EXTENSION UPDATE", which
> people are not likely to do in a minor update. But also, we don't
> know of live attacks against these fu
Michael Paquier writes:
> I was wondering what was going on here, and this patch comes down to
> switching all these definitions from that:
> CREATE FUNCTION lo_oid(lo) RETURNS pg_catalog.oid AS
> 'SELECT $1::pg_catalog.oid' LANGUAGE SQL STRICT IMMUTABLE PARALLEL SAFE;
> To that:
> +CREATE OR REP
On Tue, Nov 05, 2024 at 10:14:02AM +0100, Ronan Dunklau wrote:
> Sorry you're right I missed one for xml2. But most importantly I forgot to
> update the meson build files for every one of them, using only the Makefile...
If you want to catch that easily in the future, you can also set up
the CI w
Le lundi 4 novembre 2024, 17:10:01 heure normale d’Europe centrale Tom Lane a
écrit :
> The cfbot says many of these fail regression tests --- lots of
>
> CREATE EXTENSION citext SCHEMA s;
> +ERROR: extension "citext" has no installation script nor update path for
> version "1.8"
>
> and such.
Ronan Dunklau writes:
> Le mercredi 1 septembre 2021, 19:27:35 heure normale d’Europe centrale Tom
> Lane a écrit :
>> The rest of this is stuck pending investigation of the ideas about
>> making new-style function creation safer when the creation-time path
>> isn't secure, so I suppose we should
Le mercredi 1 septembre 2021, 19:27:35 heure normale d’Europe centrale Tom
Lane a écrit :
> The rest of this is stuck pending investigation of the ideas about
> making new-style function creation safer when the creation-time path
> isn't secure, so I suppose we should mark it RWF rather than leavi
Peter Eisentraut writes:
> On 14.04.21 00:26, Tom Lane wrote:
>> Attached are some draft patches to convert almost all of the
>> contrib modules' SQL functions to use SQL-standard function bodies.
> This first patch is still the patch of record in CF 2021-09, but from
> the subsequent discussion
On 14.04.21 00:26, Tom Lane wrote:
Attached are some draft patches to convert almost all of the
contrib modules' SQL functions to use SQL-standard function bodies.
This first patch is still the patch of record in CF 2021-09, but from
the subsequent discussion, it seems more work is being conte
On Wed, Apr 14, 2021 at 02:03:56PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Apr 14, 2021 at 1:41 PM Tom Lane wrote:
> >> Could we hack things so that extension scripts are only allowed to
> >> reference objects created (a) by the system, (b) earlier in the
> >> same script, or (c)
On 2021-Apr-15, Vik Fearing wrote:
> CREATE DOMAIN earth AS "$extension".cube.cube
> CONSTRAINT not_point check("$extension".cube.cube_is_point(value))
> CONSTRAINT not_3d check("$extension".cube.cube_dim(value <= 3)
> ...;
I find this syntax pretty weird -- here, the ".cube." part of the
i
On 4/15/21 12:18 AM, Mark Dilger wrote:
>
>
>> On Apr 14, 2021, at 2:47 PM, Vik Fearing wrote:
>>
>> On 4/14/21 7:36 PM, Tom Lane wrote:
>>> Mark Dilger writes:
> On Apr 13, 2021, at 3:26 PM, Tom Lane wrote:
> However I think we may still need an assumption that earthdistance
> and
> On Apr 14, 2021, at 2:47 PM, Vik Fearing wrote:
>
> On 4/14/21 7:36 PM, Tom Lane wrote:
>> Mark Dilger writes:
On Apr 13, 2021, at 3:26 PM, Tom Lane wrote:
However I think we may still need an assumption that earthdistance
and cube are in the same schema --- any comments on
On 4/14/21 7:36 PM, Tom Lane wrote:
> Mark Dilger writes:
>>> On Apr 13, 2021, at 3:26 PM, Tom Lane wrote:
>>> However I think we may still need an assumption that earthdistance
>>> and cube are in the same schema --- any comments on that?
>
>> This is probably not worth doing, and we are alread
Andrew Dunstan writes:
> On 4/14/21 2:03 PM, Tom Lane wrote:
>> This may mean that squeezing these contrib changes into v14 is a lost
>> cause. We certainly shouldn't try to do what I suggest above for
>> v14; but without it, these changes are just moving the security
>> issue to a different plac
On 4/14/21 2:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 14, 2021 at 1:41 PM Tom Lane wrote:
>>> Could we hack things so that extension scripts are only allowed to
>>> reference objects created (a) by the system, (b) earlier in the
>>> same script, or (c) owned by one of the dec
Robert Haas writes:
> On Wed, Apr 14, 2021 at 1:41 PM Tom Lane wrote:
>> Could we hack things so that extension scripts are only allowed to
>> reference objects created (a) by the system, (b) earlier in the
>> same script, or (c) owned by one of the declared prerequisite
>> extensions? Seems lik
On Wed, Apr 14, 2021 at 1:41 PM Tom Lane wrote:
> Doesn't help that much, because you still have to reference objects
> already created by your own extension, so it's hard to see how the
> target schema won't need to be in the path.
Oh, woops.
> Could we hack things so that extension scripts are
Robert Haas writes:
> On Wed, Apr 14, 2021 at 10:49 AM Tom Lane wrote:
>> The situation of interest is where you are trying to install an extension
>> into a schema that also contains malicious objects. We've managed to make
>> most of the commands you might use in an extension script secure aga
Mark Dilger writes:
>> On Apr 13, 2021, at 3:26 PM, Tom Lane wrote:
>> However I think we may still need an assumption that earthdistance
>> and cube are in the same schema --- any comments on that?
> This is probably not worth doing, and we are already past feature
> freeze, but adding syntax t
On Wed, Apr 14, 2021 at 10:49 AM Tom Lane wrote:
> The situation of interest is where you are trying to install an extension
> into a schema that also contains malicious objects. We've managed to make
> most of the commands you might use in an extension script secure against
> that situation, and
> On Apr 13, 2021, at 3:26 PM, Tom Lane wrote:
>
> However I think we may still need an assumption that earthdistance
> and cube are in the same schema --- any comments on that?
This is probably not worth doing, and we are already past feature freeze, but
adding syntax to look up the namespa
Robert Haas writes:
> On Wed, Apr 14, 2021 at 8:58 AM Noah Misch wrote:
>> Once CREATE EXTENSION is over, things are a great deal safer under this
>> proposal, as you say. I suspect it makes CREATE EXTENSION more hazardous.
>> Today, typical SQL commands in extension creation scripts don't activ
On Wed, Apr 14, 2021 at 8:58 AM Noah Misch wrote:
> Once CREATE EXTENSION is over, things are a great deal safer under this
> proposal, as you say. I suspect it makes CREATE EXTENSION more hazardous.
> Today, typical SQL commands in extension creation scripts don't activate
> inexact argument typ
On Tue, Apr 13, 2021 at 11:11:13PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, Apr 13, 2021 at 06:26:34PM -0400, Tom Lane wrote:
> >> Attached are some draft patches to convert almost all of the
> >> contrib modules' SQL functions to use SQL-standard function bodies.
> >> The point of
Noah Misch writes:
> On Tue, Apr 13, 2021 at 06:26:34PM -0400, Tom Lane wrote:
>> Attached are some draft patches to convert almost all of the
>> contrib modules' SQL functions to use SQL-standard function bodies.
>> The point of this is to remove the residual search_path security
>> hazards that
On Tue, Apr 13, 2021 at 06:26:34PM -0400, Tom Lane wrote:
> Attached are some draft patches to convert almost all of the
> contrib modules' SQL functions to use SQL-standard function bodies.
> The point of this is to remove the residual search_path security
> hazards that we couldn't fix in commits
43 matches
Mail list logo
