Re: Restrict user to create only one db with a specific name

Thanks David and Paul. Because each user wants the ability to drop and recreate their own databases, I want to impose a restriction on the database names. I’ll just implement what Paul has suggested. Thanks. Tiff On Sat, Mar 7, 2020 at 2:35 AM Paul Förster wrote: > Hi Tiff, > > from what you

Re: duplicate key value violates unique constraint

Asking the same question on multiple lists is strongly frowned upon. On 3/7/20 1:29 PM, Ashkar Dev wrote: Hi all, how to fix a problem, suppose there is a table with id and username if I set the id to bigint so the limit is 9223372036854775807 if I insert for example 3 rows id    username -- 

Re: duplicate key value violates unique constraint

On 3/7/20 11:29 AM, Ashkar Dev wrote: Hi all, how to fix a problem, suppose there is a table with id and username if I set the id to bigint so the limit is 9223372036854775807 if I insert for example 3 rows id    username --    -- 1     abc 2     def 3     ghi if I delete all rows

duplicate key value violates unique constraint

Hi all, how to fix a problem, suppose there is a table with id and username if I set the id to bigint so the limit is 9223372036854775807 if I insert for example 3 rows idusername ---- 1 abc 2 def 3 ghi if I delete all rows and insert one another it is like id

Re: Rules versus triggers

Yes a rule can rewrite query or replace the query Read through Depesz post about rules and the weird side affects that can occurr https://www.depesz.com/2010/06/15/to-rule-or-not-to-rule-that-is-the-question/ On Sat, Mar 7, 2020 at 9:57 AM stan wrote: > On Sat, Mar 07, 2020 at 09:47:39AM

Re: Rules versus triggers

On Sat, Mar 07, 2020 at 09:47:39AM -0500, Justin wrote: > Hi Stan > > Rules actual are able to rewrite the SQL query sent to postgresql. Most > everyone suggestion is avoid rules. > > Triggers are just like every other databases Triggers firing off code for > Insert/Update/Delete/Truncate

RAISE ERROR

I used raise(ERROR) in some functions, and it seems to work as expected, in that it aborts the statement/function and displays the message. Went to look at the documentation for this as part of my cleanup to find out this is undocumented. Should I go back and change all these calls to

Re: geting results of query in plperl

On 3/6/20 6:57 AM, stan wrote: I have looked at: https://www.postgresql.org/docs/8.4/plperl-database.html I am also comfortable querying data from tables in perl. But I do not quite see how to get the results of a query in plperl. Here is what I tried, and it is not working: my $rv2 =

Re: Rules versus triggers

Hi Stan Rules actual are able to rewrite the SQL query sent to postgresql. Most everyone suggestion is avoid rules. Triggers are just like every other databases Triggers firing off code for Insert/Update/Delete/Truncate event https://www.postgresql.org/docs/current/sql-createtrigger.html On

Re: Rules versus triggers

On 07/03/2020 11:56, stan wrote: Could someone give me a brief description of the intended functionally, and how the 2 features work of rules, versus triggers? It appears to me that they are simply 2 different ways to set up triggers, but I am certain that is just because of my lack of

Rules versus triggers

Could someone give me a brief description of the intended functionally, and how the 2 features work of rules, versus triggers? It appears to me that they are simply 2 different ways to set up triggers, but I am certain that is just because of my lack of knowledge. Thank you. -- "They that would