On 23 February 2013 14:09, <k...@roeckx.be> wrote: > My problem now is that I it's always displayed with the dashes in between, > even when I want to show the EAN13. As far as I know EANs are never shown > with the dashes.
Right, they're not. But then, contrib/isn also sanitises both ISBN ranges and EAN country codes using its own internal database, which ought to be kept in lockstep with an external database whose maintenance is highly decentralised - regional authorities make certain decisions that can create a need to update the database. I'm pretty sure that that database doesn't actually exist, at least all in one place, in the case of ISBN. So contrib/isn is fundamentally wrong-headed, and I would be quite happy to see its removal from contrib. In my experience of supply chain type applications, there is generally a need to support fairly complex custom rules for sanitising EANs, which generally makes a custom bigint domain a compelling choice. For example, sometimes (typically in situations where products are sold by weight), a price will be baked into the barcode that is affixed to the product after it is weighed on a digital scales. The last 5 digits of a barcode before the check digit is often a price (a number of cents, usually) that a scales assigns based on a known price per kilogram, plus the item's weight. This may present you with a need to store the "normalised, base barcode" (basically, just the pseudo "custom" country code and SKU) without any price, and without a check digit (the check digit is of course a function of the dynamically assigned price). There are examples for Postgres on the internet that you can generalise from for this sort of thing. These show how to enforce that a check digit is correct using SQL, using this simple method: https://en.wikipedia.org/wiki/EAN-13#Calculation_of_checksum_digit We actually discussed changing the formatting of isn along the lines you've discussed, and it was shot down. I'd just like to see it go. -- Regards, Peter Geoghegan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
