Re: Most-common value docs in PG 12

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org>
Subject: Re: Most-common value docs in PG 12
Date: 2019-09-27 11:30:49
Message-ID: 20190927113049.umhdz4khs5uvq4q7@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2019-09-27 13:59:11 Re: typo in 9.15. JSON Functions and Operators Table 9.46. JSON Processing Functions - alternate
Previous Message PG Doc comments form 2019-09-26 22:00:22 typo in 9.15. JSON Functions and Operators Table 9.46. JSON Processing Functions - alternate