Re: Domains versus arrays versus typmods
От | Robert Haas |
---|---|
Тема | Re: Domains versus arrays versus typmods |
Дата | |
Msg-id | AANLkTi=94rVW1aQ1SXbm3keJhDERgdF9qc-bsaJX4NU4@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Domains versus arrays versus typmods (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Domains versus arrays versus typmods
|
Список | pgsql-hackers |
On Tue, Oct 19, 2010 at 9:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Oct 19, 2010 at 6:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> I think that what we ought to do about it is to stop exposing typelem >>> in domains' pg_type rows. If you want to subscript a domain value, you >>> should have to drill down to its base type with getBaseTypeAndTypmod, >>> which would also give you the correct typmod to apply. If we set >>> typelem to zero in domain pg_type rows, it shouldn't take too long to >>> find any places that are missing this consideration --- the breakage >>> will be obvious rather than subtle. > >> I fear that this is going to degrade the performance of common cases >> as a way of debugging rare cases. > > We've already accepted the cost of doing getBaseTypeAndTypmod() in a > whole lot of performance-critical parsing paths, on the off chance that > the target datatype might be a domain. It's not apparent to me that > array subscripting is so important as to deserve an exemption from that. > Especially when not doing so doesn't work. Hmm... so are there no cases where zeroing out the typelem will cost us an otherwise-unnecessary syscache lookup? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: