Re: [HACKERS] pg_statistic_ext.staenabled might not be the bestcolumn name
От | Heikki Linnakangas |
---|---|
Тема | Re: [HACKERS] pg_statistic_ext.staenabled might not be the bestcolumn name |
Дата | |
Msg-id | 4313ca1d-dad2-704e-fb0f-4d556eb79894@iki.fi обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] pg_statistic_ext.staenabled might not be the bestcolumn name
|
Список | pgsql-hackers |
On 04/13/2017 03:28 PM, Tom Lane wrote: > Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: >> On 04/12/2017 03:36 PM, David Rowley wrote: >>> "stakind" seems like a better name. I'd have personally gone with >>> "statype" but pg_statistic already thinks stakind is better. > >> +1 to stakind > > I agree with that, but as long as we're rethinking column names here, > was it a good idea to use the same "sta" prefix in pg_statistic_ext > as in pg_statistic? I do not think there's anyplace else where we're > using the same table-identifying prefix in two different catalogs, > and it seems a little pointless to follow that convention at all if > we're not going to make it a unique prefix. > > We could go with "ste" perhaps, or break the convention of 3-character > prefixes and go with "stae". We have a bunch of > 3-character prefixes already: amop*, amproc*, enum*, cast*. But I think I nevertheless like "ste" better. That said, we also have two existing tables with the same prefix: pg_constraint and pg_conversion. Both use "con" as the prefix. Yes, it is a bit confusing, let's not to make the same mistake again. - Heikki
В списке pgsql-hackers по дате отправления: