Nah, it is intended to deal with 5-digit US zip codes (the majority of zip
codes we get) that have had leading zeros unduly stripped.  So the intent
is to identify these errors based on the criteria 1) that the zip code is
entirely numerical and 2) that the zip code is less than 5 digits.  Zips
containing non-numerical characters are probably from other countries
(which I don't know a standard way of attempting correction), or they could
be 9-digit US ZIPs (I could add logic for this case, but it's extremely
rare; what do you think?)


On Tue, Apr 22, 2014 at 10:10 AM, Yoshiki Vázquez Baeza <
notifications@github.com> wrote:

> In database/procedures/ag_get_barcode_metadata.sql:
>
> > @@ -150,6 +150,7 @@ select akb.barcode as sample_name,
> >          end as state,
> >          case
> >              when zip is null then 'unknown'
> > +            when regexp_like(zip, '^\d*$') then lpad(zip, 5, 0)
>
> Oh was your last change with the intent of supporting zip codes with more
> than 5 characters? What would be a good way to document this?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/qiime/qiime_web_app/pull/685/files#r11861135>
> .
>