Re: fixing CREATEROLE - Mailing list pgsql-hackers

From walther@technowledgy.de
Subject Re: fixing CREATEROLE
Date
Msg-id 073c5374-4ae6-22a3-7f0a-f54f36733611@technowledgy.de
Whole thread Raw
In response to Re: fixing CREATEROLE  (walther@technowledgy.de)
List pgsql-hackers
Wolfgang Walther:
> Tom Lane:
>> No, we don't support partial indexes on catalogs, and I don't think
>> we want to change that.  Partial indexes would require expression
>> evaluations occurring at very inopportune times.
> 
> I see. Is that the same for indexes *on* an expression? Or would those 
> be ok?
> 
> With a custom operator, an EXCLUDE constraint on the ROW(reldatabase, 
> relname) expression could work. The operator would compare:
> - (0, name1) and (0, name2) as name1 == name2
> - (db1, name1) and (0, name2) as name1 == name2
> - (0, name1) and (db2, name2) as name1 == name2
> - (db1, name1) and (db2, name2) as db1 == db2 && name1 == name2
> 
> or just (db1 == 0 || db2 == 0 || db1 == db2) && name1 == name2.

Does it even need to be on the expression? I don't think so. It would be 
enough to just make it compare relname WITH = and reldatabase WITH the 
custom operator (db1 == 0 || db2 == 0 || db1 == db2), right?

Best,

Wolfgang



pgsql-hackers by date:

Previous
From: Alexander Pyhalov
Date:
Subject: Re: Partial aggregates pushdown
Next
From: Simon Riggs
Date:
Subject: Re: Damage control for planner's get_actual_variable_endpoint() runaway