Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9rnw-005eLo-OL for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 19:39:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s9rnw-0035wp-0O for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 19:39:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9rnv-0035wh-LR for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 19:39:15 +0000 Received: from mail-yb1-xb2e.google.com ([2607:f8b0:4864:20::b2e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s9rnt-000FeK-7H for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 19:39:15 +0000 Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-df457d734abso1347191276.0 for ; Wed, 22 May 2024 12:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716406752; x=1717011552; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y/X1YXeUEYHfqBFlNoXLtgTZVrRcSYRhCZA+RcWheA4=; b=QEpzqZ+R9p8nckv8H2bIpKwIKs/NWDRZOTF6j4XepPxor3S+vNYex1j4yPhVeKqk6C 1jBFaMcn7Ylwybb1yFiB1K3IM6YYqBBxZ6Yod4I0HJnzLtkchZhrMN18p/0KSfijfR4Y 5w8vfLzk7/ml8OmBbmx2KfY3IXMvtueV1LIEQyuM5YItTPjbrIkFFdmrRXr3IIOlVF/L q0mPCdPjydB6iOCoL8ZNmd1IpAfimYZtTX54xkbxLbLrFoceuy/iGzK3zwO1gAKkOT4B aHhxk5eoBzSD6EMuFQ8Io6h7G3bh5YGACL3Kf6LIcxdZHaFOXJq392zqBcjoK4MGiM+h vA3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716406752; x=1717011552; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y/X1YXeUEYHfqBFlNoXLtgTZVrRcSYRhCZA+RcWheA4=; b=W3a9SftM7rpzW7c0+UHnyZknUPfxyp3xJgHL9FzsArrx8Ocwp3xhQ8zrHdyzPQdere 82YTB4NbQ/YeCbtex8evpjgkkcA8b09owuH53SdnkiVMG5Qm3As1L3dCVjKfomgdLslY cGNg1Oi1zUDxiMHlQ/vQPBOdcYotl7SpIjj78xAWAtJxCVZi3sU+St4jrXqJkHXTwu5Y pq28k5SqUGnM6A+0zhmJoMldV5/iHpnypUINMPBppR/iASIo+9FkzttVkJrkvTyzeqRE MozWr4zcCK6vzXZCirzkLepe2MNnH/occVFgXWnCQ1WwI+qqzK79KYsJsIjRjtcjI4R6 DSxQ== X-Gm-Message-State: AOJu0YyG00WB98EIjtD08fWNtCunySpoBhnwPThDLA7JgJINcV1Oj7mf 619zYgE39zzri/nQqiev70I0s0qp9VXEVF2JlprSGgn+CFXQJWABd/GuDr4Q80cK01GvVioq8hc SuT/Xy+xn3eaWa0CMeDVkkZnJdjM= X-Google-Smtp-Source: AGHT+IECBiQ1kgbg83bLMViihD0U10CAq9n+/6WR2EctUhiyKo+FB3WqtX4WGKVcsKdQtydoP6y1FyQuy3sV8I1WHp0= X-Received: by 2002:a25:8588:0:b0:df4:da84:195e with SMTP id 3f1490d57ef6-df4e0bda285mr3190072276.22.1716406752117; Wed, 22 May 2024 12:39:12 -0700 (PDT) MIME-Version: 1.0 References: <4178924.1716400730@sss.pgh.pa.us> In-Reply-To: From: Pavel Stehule Date: Wed, 22 May 2024 21:38:35 +0200 Message-ID: Subject: Re: search_path wildcard? To: Ron Johnson Cc: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000c0095c06191016f6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c0095c06191016f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable st 22. 5. 2024 v 21:13 odes=C3=ADlatel Ron Johnson napsal: > On Wed, May 22, 2024 at 1:58=E2=80=AFPM Tom Lane wrot= e: > >> Ron Johnson writes: >> > That would be a helpful feature for administrators, when there are >> multiple >> > schemas in multiple databases, on multiple servers: superusers get ALT= ER >> > ROLE foo SET SEARCH_PATH =3D '*'; and they're done with it. >> >> ... and they're pwned within five minutes by any user with the wits >> to create a trojan-horse function or operator. Generally speaking, >> you want admins to run with a minimal search path not a maximal one. >> > > Missing tables when running "\t" is a bigger hassle. > what is hard on \dt *.* or you can define own dtall =3D '\\dt *.*' :dtall The problem is not on search path, but maybe on design backslash commands - but there should be some level of consistency Regards Pavel --000000000000c0095c06191016f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
st 22. 5. 2024 v=C2=A021:13 odes=C3= =ADlatel Ron Johnson <ronljoh= nsonjr@gmail.com> napsal:
On Wed, May 22, 2024 at = 1:58=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ron Johnson <ronljohnsonjr@gmail.= com> writes:
> That would be a helpful feature for administrators, when there are mul= tiple
> schemas in multiple databases, on multiple servers: superusers get ALT= ER
> ROLE foo SET SEARCH_PATH=C2=A0 =3D '*'; and they're done w= ith it.

... and they're pwned within five minutes by any user with the wits
to create a trojan-horse function or operator.=C2=A0 Generally speaking, you want admins to run with a minimal search path not a maximal one.
=C2=A0
Missing tables when running "\t" = is a bigger hassle.

what = is hard on \dt *.*

or you can define own=C2=A0

=C2=A0dtall =3D '\\dt *.*'

:dtall

The problem is not on search path, b= ut maybe on design backslash commands - but there should be some level of c= onsistency

Regards

Pavel<= br>
--000000000000c0095c06191016f6--