On Thu, Sep 19, 2019 at 03:54:40PM -0600, Michael Lewis wrote:
> You can also look at citext type to avoid the casting.
Oh, that looks really useful I think I will go back and use that type quite
a bit.
Thanks for pointing it out to me.
>
> customer_keyinteger DEFAULT
> next
I see that you've already been pointed at citext, but I don't think a CHECK
constraint has been mentioned. In case it hasn't, what about something like
this?
ADD CONSTRAINT check_activity_status
CHECK (activity_status = 'ACTIVE' OR activity_status = 'INACTIVE');
I'm kind of allergic to ENU
On Thu, Sep 19, 2019 at 03:54:40PM -0600, Michael Lewis wrote:
> You can also look at citext type to avoid the casting.
>
> customer_keyinteger DEFAULT
> nextval('customer_key_serial') PRIMARY KEY ,
> cust_no smallint NOT NULL UNIQUE ,
> name
On Fri, Sep 20, 2019 at 08:52:00PM +1000, Morris de Oryx wrote:
> I see that you've already been pointed at citext, but I don't think a CHECK
> constraint has been mentioned. In case it hasn't, what about something like
> this?
>
>ADD CONSTRAINT check_activity_status
> CHECK (activity_st
Hi - I’m working on a database that will be accessed via a web app. I’m
used to a setup where there is one account/role that the app would use to
access the database, but in my current scenario I’m interested in row level
security and auditing enforced by the database. In this scenario, would it
ma
On 20/09/2019 12:50, David Gallagher wrote:
> Hi - I’m working on a database that will be accessed via a web app.
> I’m used to a setup where there is one account/role that the app would
> use to access the database, but in my current scenario I’m interested
> in row level security and auditing enf
On 20/9/19 2:50 μ.μ., David Gallagher wrote:
Hi - I’m working on a database that will be accessed via a web app. I’m used to a setup where there is one account/role that the app would use to access the database, but in my current scenario I’m
interested in row level security and auditing enforced
citext is an extension, so you have to install it:
CREATE EXTENSION citext;
That's the simplest form. you can install it into a specific schema, test
for existence, etc. Check out the CREATE EXTENSION docs here:
https://www.postgresql.org/docs/current/sql-createextension.html
> On Sep 20, 2019, at 6:15 AM, Tim Clarke wrote:
>
>> On 20/09/2019 12:50, David Gallagher wrote:
>> Hi - I’m working on a database that will be accessed via a web app.
>> I’m used to a setup where there is one account/role that the app would
>> use to access the database, but in my current sc
Rob Sargent writes:
>> On Sep 20, 2019, at 6:15 AM, Tim Clarke wrote:
> On 20/09/2019 12:50, David Gallagher wrote:
>>> ... would it make sense to have a user account on the database
>>> to mirror the user account from the web app? Is that an unusual practice?
>> Not at all, we're doing it
> Bu
Hi,
When I am setting up keeper ,
[postgres@lablnxdb001 ~]$ pg_autoctl run --pgdata /opt/primary
08:51:03 INFO Managing PostgreSQL installation at "/opt/primary"
08:51:03 INFO PostgreSQL is running in "/opt/primary" on port 6433
08:51:03 ERROR default_version or installed_version for ext
Hi,
When I am setting up keeper ,
[postgres@lablnxdb001 ~]$ pg_autoctl run --pgdata /opt/primary
08:51:03 INFO Managing PostgreSQL installation at "/opt/primary"
08:51:03 INFO PostgreSQL is running in "/opt/primary" on port 6433
08:51:03 ERROR default_version or installed_version for extension
I was pointed to the citext type to help solve an issue for a project I am
working on. I looked at this page:
https://nandovieira.com/using-insensitive-case-columns-in-postgresql-with-citext
But I must be doing something wrong. As the PG superuser, I did this:
postgres=# CREATE EXTENSION IF NOT E
Hi Good Morning Teams,
We are trying to configure pgwatch2 to monitor our postgress database named
cemtore ( version 10.3).
We have installed the pgwatch2 docker container from GitHub and followed the
steps under the section 'Steps to configure your database for monitoring' for
monitoring state
stan writes:
> But I must be doing something wrong. As the PG superuser, I did this:
> postgres=# CREATE EXTENSION IF NOT EXISTS citext WITH SCHEMA public;
> CREATE EXTENSION
> and as the superuser it shows up in the \dx display
> BUT as a normal user:
> stan=> \dx
> List of installed extension
> On Sep 20, 2019, at 1:12 PM, Tom Lane wrote:
>
> stan writes:
>> But I must be doing something wrong. As the PG superuser, I did this:
>> postgres=# CREATE EXTENSION IF NOT EXISTS citext WITH SCHEMA public;
>> CREATE EXTENSION
>
>> and as the superuser it shows up in the \dx display
>
>>
Not sure about best practices, but what I'm going is like this:
* Create a schema named extensions.
* Install extensions in this special schema only. I don't put anything else
in there.
* Put the extensions schema early (left) in the search_path for each role.
* Grant execute access permissivel
17 matches
Mail list logo
