New ISBN/ISSN/ISMN/EAN13 module.

From: "Kronuz !" <kronuz(at)hotmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: New ISBN/ISSN/ISMN/EAN13 module.
Date: 2004-11-05 02:21:28
Message-ID: BAY8-F613AmsfGdMNFm00005f03@hotmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,
I'm working on a new module to handle EAN13, ISBN, ISMN, and ISSN.
The new module validates, and automatically adds the correct hyphenations of
the numbers. Also it supports the new ISBN 13 number to be used starting on
2005.
This is my first module, and it's almost done, but I'm having some problems
with the SQL part of it.

Premises:
1. ISBN13, ISMN13, ISSN13 numbers are all EAN13 numbers
2. EAN13 numbers aren't always ISBN13 or ISMN13 or ISSN13 (some are)
3. some ISBN13 numbers can be displayed as ISBN
4. some ISMN13 numbers can be displayed as ISMN
5. some ISSN13 numbers can be displayed as ISSN
6. All types are internally represented as 64 bits integers,
and internally all are interchangeable.

We need the following data types:

+ EAN13 for European Article Numbers.
This type will always show the EAN13-display format.
Te output function for this is -> ean13_out()

+ ISBN13 for International Standard Book Numbers to be displayed in the new
EAN13-display format.
+ ISMN13 for International Standard Music Numbers to be displayed in the new
EAN13-display format.
+ ISSN13 for International Standard Serial Numbers to be displayed in the
new EAN13-display format.
These types will always display the long version of the ISxN (EAN 13).
The output function to do this is -> ean13_out()
* The need for these types is just for displaying in different ways the
same data:
ISBN13 is acctually the same as ISBN, ISMN13 = ISMN, and ISSN13 =
ISSN.

+ ISBN for International Standard Book Numbers to be displayed in the
current short-display format.
+ ISMN for International Standard Music Numbers to be displayed in the
current short-display format.
+ ISSN for International Standard Serial Numbers to be displayed in the
current short-display format.
These types will display the short version of the ISxN (ISxN 10)
whenever it's possible,
and it will show ISxN 13 when it's impossible to show the short version.
The output function to do this is -> isbn_out()

We need the following input functions:
+ A function that takes a string and returns a EAN13 -> ean13_in()
+ A function that takes a string and returns valid ISBN or ISBN13 numbers ->
isbn_in()
+ A function that takes a string and returns valid ISMN or ISMN13 numbers ->
ismn_in()
+ A function that takes a string and returns valid ISSN or ISSN13 numbers ->
issn_in()

We need to be able to cast from:
+ ISBN13 -> EAN13
+ ISMN13 -> EAN13
+ ISSN13 -> EAN13

+ ISBN -> EAN13
+ ISMN -> EAN13
+ ISSN -> EAN13

+ ISBN <-> ISBN13
+ ISMN <-> ISMN13
+ ISSN <-> ISSN13

We need an operator class so each type can be indexed (should use the same
method as int8 since
the ISN/13 EAN13 types are all internally integers (int64)

The C API is implemented as:
extern Datum isn_out(PG_FUNCTION_ARGS);
extern Datum ean13_out(PG_FUNCTION_ARGS);
extern Datum ean13_in(PG_FUNCTION_ARGS);
extern Datum isbn_in(PG_FUNCTION_ARGS);
extern Datum ismn_in(PG_FUNCTION_ARGS);
extern Datum issn_in(PG_FUNCTION_ARGS);

On success:
+ isn_out() takes any of our types and returns a string containing
the shortes possible representation of the number.

+ ean13_out() takes any of our types and returns the
EAN13 (long) representation of the number.

+ ean13_in() takes a string and return a EAN13. Which, as stated in (2)
could or could not be any of our types, but it certainly is an EAN13
number. Only if the string is a valid EAN13 number, otherwise it fails.

+ isbn_in() takes a string and return an ISBN/ISBN13. Only if the string is
really a ISBN/ISBN13, otherwise it fails.

+ ismn_in() takes a string and return an ISMN/ISMN13. Only if the string is
really a ISMN/ISMN13, otherwise it fails.

+ issn_in() takes a string and return an ISSN/ISSN13. Only if the string is
really a ISSN/ISSN13, otherwise it fails.

(on failure, the functions ereport the error)

Any suggestions on how to implement the corresponding functions, operators,
operator classes,
and casts for this PGSQL module? are more API functions needed?

Thanks,
Kronuz.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.com/

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2004-11-05 02:24:19 fsm_ variables ...
Previous Message Marc G. Fournier 2004-11-05 02:19:12 Re: [pgsql-www] pg_autovacuum is nice ... but ...