pg_statistic_ext.staenabled might not be the best column name

Started by David Rowleyabout 9 years ago9 messageshackers
Jump to latest
#1David Rowley
dgrowleyml@gmail.com

I'd been thinking that staenabled is not the most suitable column name
for storing the types of statistics that are defined for the extended
statistics. For me, this indicates that something can be disabled,
but there's no syntax for that, and even if there was, if we were to
enable/disable the kinds, we'd likely want to keep tabs on which kinds
were originally defined, otherwise it's more of an ADD and DROP than
an ENABLE/DISABLE.

"stakind" seems like a better name. I'd have personally gone with
"statype" but pg_statistic already thinks stakind is better.

A patch which changes this is attached

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachments:

ext_stats_rename_staenabled.patchapplication/octet-stream; name=ext_stats_rename_staenabled.patchDownload+67-63
#2Robert Haas
robertmhaas@gmail.com
In reply to: David Rowley (#1)
Re: pg_statistic_ext.staenabled might not be the best column name

On Wed, Apr 12, 2017 at 9:36 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:

I'd been thinking that staenabled is not the most suitable column name
for storing the types of statistics that are defined for the extended
statistics.

+1.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Tomas Vondra
tomas.vondra@2ndquadrant.com
In reply to: David Rowley (#1)
Re: pg_statistic_ext.staenabled might not be the best column name

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

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tomas Vondra (#3)
Re: pg_statistic_ext.staenabled might not be the best column name

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".

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#5Heikki Linnakangas
heikki.linnakangas@enterprisedb.com
In reply to: Tom Lane (#4)
Re: pg_statistic_ext.staenabled might not be the best column name

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#6Peter Eisentraut
peter_e@gmx.net
In reply to: Heikki Linnakangas (#5)
Re: pg_statistic_ext.staenabled might not be the best column name

On 4/13/17 08:37, Heikki Linnakangas wrote:

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.

"stx" perhaps?

I would also be in favor of changing it to something other than "sta".

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#6)
Re: pg_statistic_ext.staenabled might not be the best column name

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

On 4/13/17 08:37, Heikki Linnakangas wrote:

We have a bunch of > 3-character prefixes already: amop*, amproc*,
enum*, cast*. But I think I nevertheless like "ste" better.

"stx" perhaps?

I would also be in favor of changing it to something other than "sta".

"stx" sounds pretty good to me --- it seems like e.g. "stxkind" is
more visibly distinct from "stakind" than "stekind" would be.

Any objections out there?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#8Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Tom Lane (#7)
Re: pg_statistic_ext.staenabled might not be the best column name

Tom Lane wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

On 4/13/17 08:37, Heikki Linnakangas wrote:

We have a bunch of > 3-character prefixes already: amop*, amproc*,
enum*, cast*. But I think I nevertheless like "ste" better.

"stx" perhaps?

I would also be in favor of changing it to something other than "sta".

"stx" sounds pretty good to me --- it seems like e.g. "stxkind" is
more visibly distinct from "stakind" than "stekind" would be.

Any objections out there?

stx sounds good to me too. I'll see about a patch this afternoon.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#9Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Alvaro Herrera (#8)
Re: pg_statistic_ext.staenabled might not be the best column name

Alvaro Herrera wrote:

Tom Lane wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

On 4/13/17 08:37, Heikki Linnakangas wrote:

We have a bunch of > 3-character prefixes already: amop*, amproc*,
enum*, cast*. But I think I nevertheless like "ste" better.

"stx" perhaps?

I would also be in favor of changing it to something other than "sta".

"stx" sounds pretty good to me --- it seems like e.g. "stxkind" is
more visibly distinct from "stakind" than "stekind" would be.

Any objections out there?

stx sounds good to me too. I'll see about a patch this afternoon.

Took me a bit longer than I had hoped, but it's done now.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers