| From: | walther(at)technowledgy(dot)de |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fixing CREATEROLE |
| Date: | 2022-11-22 16:11:11 |
| Message-ID: | 073c5374-4ae6-22a3-7f0a-f54f36733611@technowledgy.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2022-11-22 16:17:34 | Re: Damage control for planner's get_actual_variable_endpoint() runaway |
| Previous Message | Alexander Pyhalov | 2022-11-22 16:05:29 | Re: Partial aggregates pushdown |