On Mon, Jun 7, 2021, at 23:26, David G. Johnston wrote:
> On Mon, Jun 7, 2021 at 1:55 PM Joel Jacobson wrote:
>> __
>> If we don't like "UNQUALIFIED" as a keyword, maybe we could reuse "PUBLIC"?
>> Or will that be confusing since "PUBLIC" is also a role_specification?
>>
>
> For me the concept
On Mon, Jun 7, 2021 at 1:55 PM Joel Jacobson wrote:
> If we don't like "UNQUALIFIED" as a keyword, maybe we could reuse "PUBLIC"?
> Or will that be confusing since "PUBLIC" is also a role_specification?
>
>
For me the concept resembles explicitly denoting certain schemas as being
simple tags,
On Mon, Jun 7, 2021 at 2:09 PM David G. Johnston
wrote:
> On Fri, Jun 4, 2021 at 9:03 AM Pavel Stehule
> wrote:
>
>> pá 4. 6. 2021 v 17:43 odesílatel Joel Jacobson
>> napsal:
>>
>>> Maybe this could work:
>>> CREATE SCHEMA schema_name UNQUALIFIED;
>>> Which would explicitly make all the
On Fri, Jun 4, 2021 at 9:03 AM Pavel Stehule
wrote:
> pá 4. 6. 2021 v 17:43 odesílatel Joel Jacobson napsal:
>
>> Maybe this could work:
>> CREATE SCHEMA schema_name UNQUALIFIED;
>> Which would explicitly make all the objects created in the schema
>> accessible unqualified, but also enforce
On Fri, Jun 4, 2021, at 18:03, Pavel Stehule wrote:
>
>
> pá 4. 6. 2021 v 17:43 odesílatel Joel Jacobson napsal:
>> __
>> Maybe this could work:
>> CREATE SCHEMA schema_name UNQUALIFIED;
>> Which would explicitly make all the objects created in the schema accessible
>> unqualified, but also
pá 4. 6. 2021 v 17:43 odesílatel Joel Jacobson napsal:
> Maybe this could work:
> CREATE SCHEMA schema_name UNQUALIFIED;
> Which would explicitly make all the objects created in the schema
> accessible unqualified, but also enforce there are no conflicts with other
> objects in existence in all
Maybe this could work:
CREATE SCHEMA schema_name UNQUALIFIED;
Which would explicitly make all the objects created in the schema accessible
unqualified, but also enforce there are no conflicts with other objects in
existence in all unqualified schemas, upon the creation of new objects.
/Joel
On Fri, Jun 4, 2021, at 11:45, Pavel Stehule wrote:
>
>
> pá 4. 6. 2021 v 11:17 odesílatel Joel Jacobson napsal:
>> __
>> On Fri, Jun 4, 2021, at 08:58, Pavel Stehule wrote:
>>> It is the same as using the command line without the possibility to
>>> customize the PATH variable. The
pá 4. 6. 2021 v 11:17 odesílatel Joel Jacobson napsal:
> On Fri, Jun 4, 2021, at 08:58, Pavel Stehule wrote:
>
> It is the same as using the command line without the possibility to
> customize the PATH variable. The advantages and disadvantages are exactly
> the same.
>
>
> The reason why we
On Fri, Jun 4, 2021, at 08:58, Pavel Stehule wrote:
> It is the same as using the command line without the possibility to customize
> the PATH variable. The advantages and disadvantages are exactly the same.
The reason why we even have PATH in the *nix world,
is not because they *wanted* to
Hi
>
> I realise "eliminate" is not really necessary, it would suffice to just
> allow setting a a sane default per database, and make that value immutable,
> then all data structures and code using wouldn't need to change, one would
> then only need to change the code that can mutate
On Thu, Jun 3, 2021, at 20:42, Isaac Morland wrote:
> I also want to mention that I consider any suggestion to eliminate the
> search_path concept as a complete non-starter.
>
> It would be no different from proposing that the next version of a
> programming language eliminate (or stop using)
čt 3. 6. 2021 v 21:11 odesílatel Mark Dilger
napsal:
>
>
> > On Jun 3, 2021, at 12:06 PM, Pavel Stehule
> wrote:
> >
> >
> >
> > čt 3. 6. 2021 v 20:25 odesílatel Mark Dilger <
> mark.dil...@enterprisedb.com> napsal:
> >
> >
> > > On Jun 3, 2021, at 9:38 AM, Pavel Stehule
> wrote:
> > >
> > >
> On Jun 3, 2021, at 12:06 PM, Pavel Stehule wrote:
>
>
>
> čt 3. 6. 2021 v 20:25 odesílatel Mark Dilger
> napsal:
>
>
> > On Jun 3, 2021, at 9:38 AM, Pavel Stehule wrote:
> >
> > This design looks good for extensions, but I am not sure if it is good for
> > users. Some declarative
čt 3. 6. 2021 v 20:25 odesílatel Mark Dilger
napsal:
>
>
> > On Jun 3, 2021, at 9:38 AM, Pavel Stehule
> wrote:
> >
> > This design looks good for extensions, but I am not sure if it is good
> for users. Some declarative way without necessity to programming or install
> some extension can be
I thought everybody was already doing this, but maybe not. I put the
following in all my function definitions:
SET search_path FROM CURRENT
(with the exception of a very few functions which explicitly need to use
the caller's search path)
It seems to me that if this was the default (note:
> On Jun 3, 2021, at 9:38 AM, Pavel Stehule wrote:
>
> This design looks good for extensions, but I am not sure if it is good for
> users. Some declarative way without necessity to programming or install some
> extension can be nice.
I agree, though "some declarative way" is a bit vague.
čt 3. 6. 2021 v 18:30 odesílatel Mark Dilger
napsal:
>
>
> > On Jun 3, 2021, at 9:03 AM, Pavel Stehule
> wrote:
> >
> > I agree so some possibility of locking search_path or possibility to
> control who and when can change it can increase security. This should be a
> core feature. It's maybe
On Thu, Jun 3, 2021 at 7:30 PM Mark Dilger
wrote:
> > On Jun 3, 2021, at 9:03 AM, Pavel Stehule
> wrote:
> >
> > I agree so some possibility of locking search_path or possibility to
> control who and when can change it can increase security. This should be a
> core feature. It's maybe more
> On Jun 3, 2021, at 9:03 AM, Pavel Stehule wrote:
>
> I agree so some possibility of locking search_path or possibility to control
> who and when can change it can increase security. This should be a core
> feature. It's maybe more generic issue - same functionality can be required
> for
čt 3. 6. 2021 v 17:54 odesílatel Marko Tiikkaja napsal:
> On Thu, Jun 3, 2021 at 9:14 AM Joel Jacobson wrote:
>
>> On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote:
>>
>> They still show up everywhere when looking at "public". So this is only
>> slightly better, and a maintenance burden.
>>
On Thu, Jun 3, 2021 at 9:14 AM Joel Jacobson wrote:
> On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote:
>
> They still show up everywhere when looking at "public". So this is only
> slightly better, and a maintenance burden.
>
>
> Good point. I find this annoying as well sometimes.
>
> It's
čt 3. 6. 2021 v 8:14 odesílatel Joel Jacobson napsal:
> On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote:
>
> On Wed, Jun 2, 2021 at 11:32 PM Joel Jacobson wrote:
>
> But if running a recent PostgreSQL version, with support for extensions, I
> think an even cleaner solution
> would be to
On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote:
> On Wed, Jun 2, 2021 at 11:32 PM Joel Jacobson wrote:
>> __But if running a recent PostgreSQL version, with support for extensions, I
>> think an even cleaner solution
>> would be to package such compatibility versions in a "compat"
On Wed, Jun 2, 2021 at 11:32 PM Joel Jacobson wrote:
> On Wed, Jun 2, 2021, at 18:36, Marko Tiikkaja wrote:
>
> The use case is: version upgrades. I want to be able to have a
> search_path of something like 'pg_catalog, compat, public'. That way we
> can provide compatibility versions of newer
On Wed, Jun 2, 2021 at 10:20 PM Alvaro Herrera
wrote:
> On 2021-Jun-02, Marko Tiikkaja wrote:
>
> > The use case is: version upgrades. I want to be able to have a
> search_path
> > of something like 'pg_catalog, compat, public'. That way we can provide
> > compatibility versions of newer
On Wed, Jun 2, 2021, at 18:36, Marko Tiikkaja wrote:
> On Wed, Jun 2, 2021 at 3:46 PM Joel Jacobson wrote:
>> If a database object is to be accessed unqualified by all users, isn't the
>> 'public' schema a perfect fit for it? How will it be helpful to create
>> different database objects in
On 2021-Jun-02, Marko Tiikkaja wrote:
> The use case is: version upgrades. I want to be able to have a search_path
> of something like 'pg_catalog, compat, public'. That way we can provide
> compatibility versions of newer functions in the "compat" schema, which get
> taken over by pg_catalog
On Wed, Jun 02, 2021 at 02:46:08PM +0200, Joel Jacobson wrote:
>
> But perhaps the search_path as an uninstallable extension is a less invasive
> idea.
I don't that that happening any time soon. An extension only adds SQL objects,
it doesn't impact backend code. You can ship a module with
st 2. 6. 2021 v 14:46 odesílatel Joel Jacobson napsal:
> On Wed, Jun 2, 2021, at 09:07, Pavel Stehule wrote:
>
> st 2. 6. 2021 v 8:45 odesílatel Joel Jacobson napsal:
>
> 'search_path' is a bit like a global variable in C, that can change the
> behaviour of the SQL commands executed.
> It makes
On Wed, Jun 2, 2021 at 3:46 PM Joel Jacobson wrote:
> If a database object is to be accessed unqualified by all users, isn't the
> 'public' schema a perfect fit for it? How will it be helpful to create
> different database objects in different schemas, if also adding all such
> schemas to the
On Wed, Jun 2, 2021, at 09:07, Pavel Stehule wrote:
> st 2. 6. 2021 v 8:45 odesílatel Joel Jacobson napsal:
>> __'search_path' is a bit like a global variable in C, that can change the
>> behaviour of the SQL commands executed.
>> It makes unqualified SQL code context-sensitive; you don't know
st 2. 6. 2021 v 8:45 odesílatel Joel Jacobson napsal:
> On Tue, Jun 1, 2021, at 18:05, Pavel Stehule wrote:
>
> I learned programming on Orafce, and I didn't expect any success, so I
> designed it quickly, and the placing of old Orafce's functions to schemas
> is messy.
>
> I am sure, if I
On Tue, Jun 1, 2021, at 18:05, Pavel Stehule wrote:
> I learned programming on Orafce, and I didn't expect any success, so I
> designed it quickly, and the placing of old Orafce's functions to schemas is
> messy.
>
> I am sure, if I started again, I would never use pg_catalog or public schema.
út 1. 6. 2021 v 17:57 odesílatel Joel Jacobson napsal:
> On Tue, Jun 1, 2021, at 14:41, Pavel Stehule wrote:
>
> út 1. 6. 2021 v 13:13 odesílatel Joel Jacobson napsal:
>
> I don't agree. If an extension provides functionality that is supposed to
> be used by all parts of the system, then I
On Tue, Jun 1, 2021, at 14:41, Pavel Stehule wrote:
> út 1. 6. 2021 v 13:13 odesílatel Joel Jacobson napsal:
>> __I don't agree. If an extension provides functionality that is supposed to
>> be used by all parts of the system, then I think the 'public' schema is a
>> good choice.
>
> I
út 1. 6. 2021 v 13:13 odesílatel Joel Jacobson napsal:
> On Tue, Jun 1, 2021, at 12:55, Pavel Stehule wrote:
>
>
>
> út 1. 6. 2021 v 12:53 odesílatel Joel Jacobson napsal:
>
> On Tue, Jun 1, 2021, at 10:44, Pavel Stehule wrote:
>
> Operators use schemas too. I cannot imagine any work with
On Tue, Jun 1, 2021, at 12:55, Pavel Stehule wrote:
>
>
> út 1. 6. 2021 v 12:53 odesílatel Joel Jacobson napsal:
>> On Tue, Jun 1, 2021, at 10:44, Pavel Stehule wrote:
>>> Operators use schemas too. I cannot imagine any work with operators with
>>> the necessity of explicit schemas.
>>
>> I
út 1. 6. 2021 v 12:53 odesílatel Joel Jacobson napsal:
> On Tue, Jun 1, 2021, at 10:44, Pavel Stehule wrote:
>
> Operators use schemas too. I cannot imagine any work with operators with
> the necessity of explicit schemas.
>
>
> I thought operators are mostly installed in the public schema, in
On Tue, Jun 1, 2021, at 10:44, Pavel Stehule wrote:
> Operators use schemas too. I cannot imagine any work with operators with the
> necessity of explicit schemas.
I thought operators are mostly installed in the public schema, in which case
that wouldn't be a problem, or am I missing something
út 1. 6. 2021 v 8:59 odesílatel Joel Jacobson napsal:
> On Sun, May 30, 2021, at 09:54, Pavel Stehule wrote:
>
> Maybe inverted design can work better - there can be GUC -
> "qualified_names_required" with a list of schemas without enabled implicit
> access.
>
> The one possible value can be
On Sun, May 30, 2021, at 09:54, Pavel Stehule wrote:
> Maybe inverted design can work better - there can be GUC -
> "qualified_names_required" with a list of schemas without enabled implicit
> access.
>
> The one possible value can be "all".
>
> The advantage of this design can be the
ne 30. 5. 2021 v 8:52 odesílatel Joel Jacobson napsal:
> On Sat, May 29, 2021, at 22:10, Marko Tiikkaja wrote:
>
> On Sat, May 29, 2021 at 11:06 PM Joel Jacobson wrote:
>
>
> Glad you bring this problem up for discussion, something should be done to
> improve the situation.
>
> Personally, as I
On Sun, May 30, 2021, at 08:51, Joel Jacobson wrote:
> Maybe this is out of scope for extensions, since I guess extensions are
> supposed to add features?
>
> If so, how about a new separate command `CREATE REDUCTION` specifically to
> remove unwanted core features,
> which then wouldn't need
On Sat, May 29, 2021, at 22:10, Marko Tiikkaja wrote:
> On Sat, May 29, 2021 at 11:06 PM Joel Jacobson wrote:
>> __
>> Glad you bring this problem up for discussion, something should be done to
>> improve the situation.
>>
>> Personally, as I really dislike search_path and consider using it an
On Sat, May 29, 2021 at 11:06 PM Joel Jacobson wrote:
> Glad you bring this problem up for discussion, something should be done to
> improve the situation.
>
> Personally, as I really dislike search_path and consider using it an
> anti-pattern.
> I would rather prefer a GUC to hard-code
Glad you bring this problem up for discussion, something should be done to
improve the situation.
Personally, as I really dislike search_path and consider using it an
anti-pattern.
I would rather prefer a GUC to hard-code search_path to a constant default
value of just ‘public’ that cannot be
Hi,
Since writing SECURITY DEFINER functions securely requires annoying
incantations[1], wouldn't it be nice if we provided a way for the superuser
to override the default search path via a GUC in postgresql.conf? That way
you can set search_path if you want to override the default, but if you
48 matches
Mail list logo
