Re: Most-common value docs in PG 12 - Mailing list pgsql-docs

From Tomas Vondra
Subject Re: Most-common value docs in PG 12
Date
Msg-id 20190927113049.umhdz4khs5uvq4q7@development
Whole thread Raw
In response to Re: Most-common value docs in PG 12  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Most-common value docs in PG 12
List pgsql-docs
On Thu, Sep 26, 2019 at 05:31:07PM -0400, Bruce Momjian wrote:
>On Thu, Sep 26, 2019 at 11:03:54PM +0200, Tomas Vondra wrote:
>> On Thu, Sep 26, 2019 at 04:20:59PM -0400, Bruce Momjian wrote:
>> > Uh, people normally list things in defined order, so you would usually
>> > not list them in non-defined order unless there is a purpose.  Doing
>> > that just to illustrate the order doesn't matter seems odd.
>> >
>>
>> Well, that assumes there is a definition, and I don't think the zipcodes
>> table is defined anywhere. So how do you know in what order are those
>> columns defined?
>
>In the USA, it is usually specific to general, i.e., city, state.
>

I'd probably define it the same way, but for example the zipcode data
sets I usually use for my talks [1] defines it like this:

  postal code       : varchar(20)
  place name        : varchar(180)
  admin name1       : 1. order subdivision (state) varchar(100)
  admin code1       : 1. order subdivision (state) varchar(20)
  admin name2       : 2. order subdivision (county/province) varchar(100)
  admin code2       : 2. order subdivision (county/province) varchar(20)
  admin name3       : 3. order subdivision (community) varchar(100)
  admin code3       : 3. order subdivision (community) varchar(20)
  latitude          : estimated latitude (wgs84)
  longitude         : estimated longitude (wgs84)
  accuracy          : accuracy of lat/lng

so in this case it's a bit of a mix of specific vs. general first. 

[1] http://download.geonames.org/export/zip/

>> Now, maybe the table should be defined somewhere in perform.sgml - I
>> don't recall why exactly I chose not to do that, maybe because there is
>> no universal definition (one country uses text, another number, ...)
>
>Yeah, doesn't seem worth adding.
>

OK.

regards

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



pgsql-docs by date:

Previous
From: PG Doc comments form
Date:
Subject: typo in 9.15. JSON Functions and Operators Table 9.46. JSON Processing Functions - alternate
Next
From: Tom Lane
Date:
Subject: Re: typo in 9.15. JSON Functions and Operators Table 9.46. JSON Processing Functions - alternate