> On 21-Oct-2021, at 17:15, Adrian Klaver wrote:
>
> On 10/21/21 15:45, Bryn Llewellyn wrote:
>>> /Adrian Klaver wrote:/
>>>
/Bryn wrote:/
>
>> Thanks, too, to David Johnston for your reply. Yes, I see now that the
>> "10.1. Overview" page that starts the "Type Conversion" chapter d
On 10/21/21 15:45, Bryn Llewellyn wrote:
/Adrian Klaver wrote:/
/Bryn wrote:/
Thanks, too, to David Johnston for your reply. Yes, I see now that the
"10.1. Overview" page that starts the "Type Conversion" chapter does
have lots of inflexions of the verb "prefer". And close to one of these
> Adrian Klaver wrote:
>
>> Bryn wrote:
>>
>> I fear that I'm about to embarrass myself again. So I'll just ask for
>> forgiveness in advance. Here's a simple test to get started. (All tests are
>> done in a session where I set the timezone to 'UTC'.)
>>
>> drop function if exists f(text)
On 10/21/21 12:52, Bryn Llewellyn wrote:
I fear that I'm about to embarrass myself again. So I'll just ask for
forgiveness in advance.
Here's a simple test to get started. (All tests are done in a session
where I set the timezone to 'UTC'.)
*drop function if exists f(text) cascade;
**
Hi,
My postgres server setup is thus: a production database, which is using WAL
streaming (hot standby) to four other hosts of various latencies. I Have a
table that is ~200GB which has been backed up, and now I Want to remove it.
The table is not in use, it is a child table to a parent table that
On Thursday, October 21, 2021, Bryn Llewellyn wrote:
>
> This causes the 42883 error, "function f(date) does not exist". I might've
> expected the system to have done an implicit conversion to "text" because
> this conversion is supported, thus:
>
Yes, implicit casting to text is bad.
>
> For
PGconf.NYC 2021 is just around the corner, and you can help us make it a
success. If you've frequented previous PostgreSQL conferences, you've seen
our enthusiastic volunteers who have helped us make the event a pleasant
experience for all our visitors. If you want to be a part of this great
team,
I fear that I'm about to embarrass myself again. So I'll just ask for
forgiveness in advance.
Here's a simple test to get started. (All tests are done in a session where I
set the timezone to 'UTC'.)
drop function if exists f(text)cascade;
drop function if exists f(timestamp) cascade;
On 10/21/21 10:44, Tom Lane wrote:
Adrian Klaver writes:
On 10/21/21 09:53, Tom Lane wrote:
I would suggest session(_)user to make it match with the rest of
documentation.
But that's not right either.
regression=# select session_user;
session_user
--
postgres
(1 row)
regr
On 10/21/21 10:51, Tom Lane wrote:
Toomas writes:
2) db=> select current_user, session_user;
current_user | session_user
--+--
db_owner | db_user
(1 row)
Given that setup, I wonder which role you expected \password to change.
If we target the current_user, we
Thanks a lot Vijay for your valuable inputs.
Best Regards,
Saurav
On Wed, Oct 20, 2021 at 1:06 AM Vijaykumar Jain <
vijaykumarjain.git...@gmail.com> wrote:
> On Tue, 19 Oct 2021 at 23:20, Vijaykumar Jain <
> vijaykumarjain.git...@gmail.com> wrote:
>
>>
>> On Tue, 19 Oct 2021 at 23:09, Vijaykumar
Toomas writes:
> 2) db=> select current_user, session_user;
> current_user | session_user
> --+--
> db_owner | db_user
> (1 row)
Given that setup, I wonder which role you expected \password to change.
If we target the current_user, we can expect the command to succ
Adrian Klaver writes:
> On 10/21/21 09:53, Tom Lane wrote:
>> I'm not sure if we want to change a security-relevant behavior
>> in released branches. But if we don't, we probably need to
>> change the docs to something like "(by default, the logged-in
>> user)".
> I would suggest session(_)user
Hi,
DB user has definition
GRANT db_owner TO db_user;
ALTER ROLE db_user IN DATABASE db SET role TO ‘db_owner’;
and user logs in with command
1) $ psql -U db_user -d db
2) db=> select current_user, session_user;
current_user | session_user
--+--
db_owner | db_use
On 10/21/21 09:53, Tom Lane wrote:
Adrian Klaver writes:
It's fairly obvious what's happening here: psql sends ALTER USER xxx
PASSWORD ..., where it gets xxx from PQuser(), so that is the role name
that was logged in with. There are any number of reasons why that might
not be the currently a
Adrian Klaver writes:
> On 10/21/21 08:39, Toomas wrote:
>> Basically the case was, when *session_user != current_user* then command
>> \password failed with error message “ERROR: permission denied”. All was
>> good when session_user == current_user.
>>
>> In terms of statement “session_user u
On 10/21/21 08:39, Toomas wrote:
Hi,
Basically the case was, when *session_user != current_user* then command
\password failed with error message “ERROR: permission denied”. All was
good when session_user == current_user.
In terms of statement “session_user user was set as the owner of the
Hi,
Basically the case was, when session_user != current_user then command
\password failed with error message “ERROR: permission denied”. All was good
when session_user == current_user.
In terms of statement “session_user user was set as the owner of the database
automatically” - I have a se
On Wed, Oct 20, 2021 at 05:46:01PM -0400, Tom Lane wrote:
> I wrote:
> > Anyway, it doesn't look like there's much hope of improving this
> > aspect without a significant rewrite.
>
> Just to close out this thread: I've now posted such a rewrite at
> https://www.postgresql.org/message-id/2273648.1
19 matches
Mail list logo
