Date: Fri, 27 Sep 2019 13:30:49 +0200
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
	PostgreSQL-documentation <pgsql-docs@postgresql.org>
Subject: Re: Most-common value docs in PG 12
Message-ID: <20190927113049.umhdz4khs5uvq4q7@development>
References: <20190926200522.GB16366@momjian.us>
 <20190926201755.GA18930@alvherre.pgsql>
 <20190926202059.GD16366@momjian.us>
 <20190926210354.dcwq5frjs44gbvkz@development>
 <20190926213107.GF16366@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20190926213107.GF16366@momjian.us>
User-Agent: NeoMutt/20180716
Precedence: bulk

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