Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Tom, I've checked the version in the cvs and I had made significant
changes
from that version.
Hm, it sounds like I guessed wrong about which version was newer ... is
there something flaky about your machine's system clock? The file
timestamps in the two tarballs definitely pointed the other way.
Nope, not a system clock problem, not that I know of... I don't know what
the problem was... anyway, with the patch I made it should now be fully
functional.
I fixed some major bugs that prevented some ISBN numbers
from working. I've merged the changes made for the cvs with my own,
hoping I
didn't miss anything that was already fixed in the cvs... I noticed you
changed some log messages and that you added GET_STR and GET_TEXT.
indeed
there was that thing that took me some time to figure in both
ean13_cast_to_text() and isn_cast_to_text() functions, not changing to a
valid TEXT the return value; but I did not know about the other
*_cast_from_text() functions having the problem of the missing GET_STR()
(I
was using VARDATA()).
Yeah, your to/from text functions simply did not work --- the VARDATA
hack for example presumes that the data part of a text value is
null-terminated, which it isn't. In any case it seems pretty likely
that the content of TEXT datums will change someday to allow better
charset/collation support, so you really are better off calling
textin/textout if possible rather than assuming you know the
representation of type TEXT. I copied the GET_STR/GET_TEXT macros
from some other contrib module ... you're free to do it differently
if you want, but in any case you have to deal with the fact that TEXT
is *not* a C-string.
Yeah, that's what I painfully learned, specially with the *_cast_to_text()
functions... those were definitely crashing the server. I didn't know the
VARDATA() hack could fail at some point (even in the patch, I already
replaced it with GET_STR(), just in case)... and since it took me so long to
figure out why the other two functions where crashing, and not knowing what
exactly was that you made with the GET_TEXT() macro, I just decided to use
my own patched version... I suppose the use of GET_TEXT() is better, as it's
smaller and makes the code easier to follow; perhaps we might want to change
those two functions back the way you had them (using GET_TEXT())
As for the log message changes, there's room for debate about that, but
the way you had it struck me as far too chatty. The use-case for weak
checking is that you have a large pile of data you don't want to
validate right now, correct? So why would you want a warning for every
single bad datum during the import? Also, all the fancy formatting in
that one big warning was directly against our message style guidelines.
That's right, that's the idea behind weak mode... I've been in that
position and I found the weak mode very useful, so I thought it would be
nice to have it as a feature that others could benefit from. And yes, I know
the messages were far too chatty, as you rightfully said so. In my latest
version (before the patch) I took away some of the messages, and I also
shortened the *big* warning to a single line
but I think not having so many
messages it's truly better; I wasn't sure when the messages were shown (this
is my first module, you know) but it seems those removed messages were
really not needed at all.
I'm very happy to have contributed a bit to the growth and improvement of
PostgreSQL, and I look forward the day I can make bigger/better
contributions. And Tom, were you able to apply the patch without problems
('cause this is one of the first times I post a patch in a mailing list.)
Regards,
Kronuz
---(end of broadcast)---
TIP 6: explain analyze is your friend
[HACKERS] ISBN/ISSN/ISMN/EAN13 module
I'm reviewing this for addition to contrib/ now. I notice that there
is
no clear license statement. Is it OK to put the following into the
README file?
Tom, yes. Also, I just put copyright in the files that contain a
significant
amount of code written by me. (i.e. isn.h and isn.c).
Excellent, thanks.
Also, did you get the 'isn-1_0_beta_20060924' version from my ftp?
'cause
thats the last one I updated (2006-09-24). It's at:
ftp://ftp.kronuz.com/pub/programming/isn-1_0_beta_20060924.tar.bz2 (just
in
case)
You had submitted two slightly different versions to the mailing list
awhile back. I took the one that seemed to have later file dates and
did some fixes/editorializations on that. Please look at what I've
just committed to PG CVS and see if you want to make any adjustments
--- if so, submit a patch through the usual pgsql-patches channel.
Tom, I've checked the version in the cvs and I had made significant changes
from that version. I fixed some major bugs that prevented some ISBN numbers
from working. I've merged the changes made for the cvs with my own, hoping I
didn't miss anything that was already fixed in the cvs... I noticed you
changed some log messages and that you added GET_STR and GET_TEXT. indeed
there was that thing that took me some time to figure in both
ean13_cast_to_text() and isn_cast_to_text() functions, not changing to a
valid TEXT the return value; but I did not know about the other
*_cast_from_text() functions having the problem of the missing GET_STR() (I
was using VARDATA()).
As I changed so much things with the patch (I'm sending the patch to
pgsql-patches too), Could you please check that those two functions
(ean13_cast_to_text() and isn_cast_to_text()) to see if the use of
GET_TEXT() would be a better option from the one I'm using? (I hope I left
all the improved messages okay)
Regards,
Kronuz.
Patch follows next:
diff -ruN oldisn/isn.c isn/isn.c
--- oldisn/isn.c2006-09-08 23:07:52.0 -0500
+++ isn/isn.c 2006-09-09 16:58:43.098148200 -0500
@@ -31,7 +31,7 @@
enum isn_type { INVALID, ANY, EAN13, ISBN, ISMN, ISSN, UPC };
-static const char *isn_names[] = { ISN, ISN, EAN13, ISBN, ISMN,
ISSN, UPC };
+static const char *isn_names[] = { EAN13/UPC/ISxN, EAN13/UPC/ISxN,
EAN13, ISBN, ISMN, ISSN, UPC };
static bool g_weak = false;
static bool g_initialized = false;
@@ -43,11 +43,11 @@
/***
**
- **Routines for ISNs.
+ **Routines for EAN13/UPC/ISxNs.
**
** Note:
** In this code, a normalized string is one that is known to be a valid
- ** ISN number containing only digits and hyphens and with enough space
+ ** ISxN number containing only digits and hyphens and with enough space
** to hold the full 13 digits plus the maximum of four hyphens.
***/
@@ -217,7 +217,7 @@
}
/*
- * weight_checkdig -- Receives a buffer with a normalized ISN string
number,
+ * weight_checkdig -- Receives a buffer with a normalized ISxN string
number,
* and the length to weight.
*
* Returns the weight of the number (the check digit value, 0-10)
@@ -239,7 +239,7 @@
/*
- * checkdig --- Receives a buffer with a normalized ISN string number,
+ * checkdig --- Receives a buffer with a normalized ISxN string number,
* and the length to check.
*
* Returns the check digit value (0-9)
@@ -267,8 +267,94 @@
}
/*
- * ean2isn --- Convert in-place a normalized EAN13 string to the
corresponding
- *ISN string number. Assumes the input string is normalized.
+ * ean2isn --- Try to convert an ean13 number to a UPC/ISxN number.
+ * This doesn't verify for a valid check digit.
+ *
+ * If errorOK is false, ereport a useful error message if the ean13 is bad.
+ * If errorOK is true, just return false for bad input.
+ */
+static
+bool ean2isn(ean13 ean, bool errorOK, ean13 *result, enum isn_type accept)
+{
+ enum isn_type type = INVALID;
+
+ char buf[MAXEAN13LEN + 1];
+ char *firstdig, *aux;
+ unsigned digval;
+ unsigned search;
+ ean13 ret = ean;
+
+ ean = 1;
+ /* verify it's in the EAN13 range */
+ if(ean UINT64CONST(9))
+ goto eantoobig;
+
+ /* convert the number */
+ search = 0;
+ firstdig = aux = buf + 13;
+ *aux = '\0';/* terminate string; aux points to last digit */
+ do {
+ digval = (unsigned)(ean % 10); /* get the decimal
value */
+ ean /= 10;
/* get next digit */
+ *--aux = (char)(digval + '0'); /* convert to
ascii and store */
+ } while(ean search++12);
+ while(search++12) *--aux = '0'; /* fill the
remaining EAN13 with '0'
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Jeremy Kronuz [EMAIL PROTECTED] writes: Tom, I've checked the version in the cvs and I had made significant changes from that version. Hm, it sounds like I guessed wrong about which version was newer ... is there something flaky about your machine's system clock? The file timestamps in the two tarballs definitely pointed the other way. I fixed some major bugs that prevented some ISBN numbers from working. I've merged the changes made for the cvs with my own, hoping I didn't miss anything that was already fixed in the cvs... I noticed you changed some log messages and that you added GET_STR and GET_TEXT. indeed there was that thing that took me some time to figure in both ean13_cast_to_text() and isn_cast_to_text() functions, not changing to a valid TEXT the return value; but I did not know about the other *_cast_from_text() functions having the problem of the missing GET_STR() (I was using VARDATA()). Yeah, your to/from text functions simply did not work --- the VARDATA hack for example presumes that the data part of a text value is null-terminated, which it isn't. In any case it seems pretty likely that the content of TEXT datums will change someday to allow better charset/collation support, so you really are better off calling textin/textout if possible rather than assuming you know the representation of type TEXT. I copied the GET_STR/GET_TEXT macros from some other contrib module ... you're free to do it differently if you want, but in any case you have to deal with the fact that TEXT is *not* a C-string. As for the log message changes, there's room for debate about that, but the way you had it struck me as far too chatty. The use-case for weak checking is that you have a large pile of data you don't want to validate right now, correct? So why would you want a warning for every single bad datum during the import? Also, all the fancy formatting in that one big warning was directly against our message style guidelines. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
I also added other functionality to the module but I forgot to update the
README... contrary to what it says in the README.isn, you do can cast from
ean13 to other types, as long as the cast is valid (i.e. you can't cast a
EAN13 of a UPC or a ISMN code to a ISBN number, for instance.)
So, the text starting at line 184 in the README.isn should say something
like this instead:
-- note that you can only cast from ean13 to other type when the casted
-- number would be valid in the realm of the casted type;
-- thus, the following will NOT work: select isbn(ean13('0220356483481'));
-- but these will:
select upc(ean13('0220356483481'));
select ean13(upc('220356483481'));
(this is not in my patch, I just realized about this)
Kronuz.
Fools rush in where fools have been before Unknown
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Jeremy Kronuz [EMAIL PROTECTED] writes: Hello again,This is an usable version of my EAN13/UPC/ISBN module. I'm reviewing this for addition to contrib/ now. I notice that there is no clear license statement. Is it OK to put the following into the README file? EAN13 - UPC - ISBN (books) - ISMN (music) - ISSN (serials) -- Copyright Germán Méndez Bravo (Kronuz), 2004 - 2006 This module is released under the same BSD license as the rest of PostgreSQL. The information to implement this module was collected through ... Tom, yes. Also, I just put copyright in the files that contain a significant amount of code written by me. (i.e. isn.h and isn.c). If you check the other files, I just put the information was recompiled from several sources and I also included the websites from where the information came. I suppose I just forgot to put the BSD license legend there in the code, so please add the line you suggested about the PostgreSQL BSD license if you want. Also, did you get the 'isn-1_0_beta_20060924' version from my ftp? 'cause thats the last one I updated (2006-09-24). It's at: ftp://ftp.kronuz.com/pub/programming/isn-1_0_beta_20060924.tar.bz2 (just in case) Kronuz. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Jeremy Kronuz [EMAIL PROTECTED] writes: I'm reviewing this for addition to contrib/ now. I notice that there is no clear license statement. Is it OK to put the following into the README file? Tom, yes. Also, I just put copyright in the files that contain a significant amount of code written by me. (i.e. isn.h and isn.c). Excellent, thanks. Also, did you get the 'isn-1_0_beta_20060924' version from my ftp? 'cause thats the last one I updated (2006-09-24). It's at: ftp://ftp.kronuz.com/pub/programming/isn-1_0_beta_20060924.tar.bz2 (just in case) You had submitted two slightly different versions to the mailing list awhile back. I took the one that seemed to have later file dates and did some fixes/editorializations on that. Please look at what I've just committed to PG CVS and see if you want to make any adjustments --- if so, submit a patch through the usual pgsql-patches channel. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Jeremy Kronuz [EMAIL PROTECTED] writes: Hello again,This is an usable version of my EAN13/UPC/ISBN module. I'm reviewing this for addition to contrib/ now. I notice that there is no clear license statement. Is it OK to put the following into the README file? EAN13 - UPC - ISBN (books) - ISMN (music) - ISSN (serials) -- Copyright Germán Méndez Bravo (Kronuz), 2004 - 2006 This module is released under the same BSD license as the rest of PostgreSQL. The information to implement this module was collected through ... regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Tom Lane wrote: Jeremy Kronuz [EMAIL PROTECTED] writes: Hello again,This is an usable version of my EAN13/UPC/ISBN module. I'm reviewing this for addition to contrib/ now. I notice that there is no clear license statement. Is it OK to put the following into the README file? EAN13 - UPC - ISBN (books) - ISMN (music) - ISSN (serials) -- Copyright Germ?n M?ndez Bravo (Kronuz), 2004 - 2006 This module is released under the same BSD license as the rest of PostgreSQL. The information to implement this module was collected through ... Do we want to go down this road for all submissions? I think saying nothing is best. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I'm reviewing this for addition to contrib/ now. I notice that there is no clear license statement. Is it OK to put the following into the README file? This module is released under the same BSD license as the rest of PostgreSQL. Do we want to go down this road for all submissions? I think saying nothing is best. The alternative is to ask him to remove his personal copyright notice and put Copyright PostgreSQL Global Development Group instead. I don't really care which, but without one or the other it's not clear that he is giving permission for redistribution. As for all submissions, I'm only concerned about the ones that come plastered with copyright notices. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I'm reviewing this for addition to contrib/ now. I notice that there is no clear license statement. Is it OK to put the following into the README file? This module is released under the same BSD license as the rest of PostgreSQL. Do we want to go down this road for all submissions? I think saying nothing is best. The alternative is to ask him to remove his personal copyright notice and put Copyright PostgreSQL Global Development Group instead. I don't really care which, but without one or the other it's not clear that he is giving permission for redistribution. Agreed. As for all submissions, I'm only concerned about the ones that come plastered with copyright notices. Oh, I didn't see one in there. Oh, I see it now in isn.c: * Copyright (c) 2004-2006, GermE1n ME9ndez Bravo (Kronuz) And when you said I notice that there is no clear license statement, I thought you meant no license at all. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
So we want to replace the isbn in /contrib with this in 8.2? --- Andrew Dunstan wrote: Michael Glaesemann wrote: On Aug 22, 2006, at 2:52 , Bruce Momjian wrote: Do we want to replace our /contrib/isbn with this, or have it pgfoundry? If contrib/isbn is made obsolete by the pgfoundry ISBN/ISSN/ISMN/EAN13 code, unless there's a compelling reason that the pgfoundry be part of the distribution, I recommend removing contrib/isbn from the core distribution and pointing people to pgfoundry. AFAIK there is no code currently on pgfoundry. We had a proposed project a little while back but the proposer got impatient and decided to withdraw it. I think that having this or a similar module in contrib has some advantages, as an example on how to do user defined types, and as a check that pgxs is working in such cases. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Michaelwrote: Idohopethatyouralgorithmforgenerating13digitsfrom10hasbeen validatedwithisbn.org,sinceallthecheckdigitswillchange.I believeitiscrucialforpostgresqltogenerateisbncodesinboth10 and13digits Indeednowthatseethemoduleit'sfinallyclosetobeacceptedasan officialmodule,I'mverifyingmyalgorithmagainsttheoneinthe ISBNUserManualandallthecurrentinformationIcangetmyhands into(Ifirstcreatedthemoduleacoupleyearsago,andtherewasn't asmuchinformationbackthen.) ThemoduleinternallykeepsallthenumbersinEAN13mode,anditonly convertsthenumberstoISBNwhenrequiredorneededbytheselected datatype. andinthetwoseparatewaysrequiredofpublisherson theirbarcodes,withjustthe10digitinput.Thisisjustaspecial casefortheoverallclassificationsystem,sotheinitial3digitcode forbookpublishersshouldnotbehardwired. Igotlostinwhatyousaidhere,couldyoupleasebemorespecific? whatisthatabouttheinitial3digitcodeyou'rementioning? doyoumean"thetwoseparateways",youmeanbothISBNandISBN13asin: ISBN-13:978-1-873671-00-9 ISBN-10:1-873671-00-8 ? Shortly,I'llbefurtherimprovingtheperformanceanddoingsome tweakinginotherareas,aswellasupdatingtheISBNhyphenation rangesandprobablyaddingUPCsupport. I'mstillnotsureiftoincludehyphenationsintheEAN13codesasit seemsit'snotpartofthestandard,thus0036000291452and 9781873671009wouldbetoexamplesofhowtheEAN13numberswouldshow withouthyphenation Thanksforyourconcerns, Kronuz. "Foolsrushinwherefoolshavebeenbefore"-Unknownthe978istheworldwideclassificationforbookpublishers.Thereisa completescheduleof3digitprefixesforallothertypesofproductsin theworld,anditsyncswithbtheNAIAC Okay, I've finally finished something usable. I'm attaching the source code in a .tgz, it should go inside thecontrib directory I suppose. I've created a README file, with some examples of how to use it, etc. The module works for EAN13, ISBN13, ISBN, ISMN, ISSN and UPC (as well as the non-standard ISMN13 and ISSN13, which are really only EAN13) Please, if you find any bugs/suggestions, please don't hesitate. Kronuz. "Foolsrushinwherefoolshavebeenbefore"-Unknown Search from any Web page with powerful protection. Get the FREE Windows Live Toolbar Today! Try it now! isn-1_0_beta_20060924.tgz Description: application/gzip-compressed ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Hello again,This is an usable version of my EAN13/UPC/ISBNmodule. It handles EAN13, ISBN13, ISBN, ISMN, ISSN, UPC and the non standard ISMN13 and ISSN13. It validates check digits and can be used to auto generate valid numbers with correct check digits too. It seems the the file I attached with my module, last time, got blocked from the mailing lists, I'm attaching the module once again with some extra modifications and a couple bug fixes. I'm also publishing the ftp URL here, though my ftp serverit's only up when I'm connected... if anyone's interested to provide a few kilobytes of space for me to put my module, please let me know.ftp://ftp.kronuz.com/pub/programming/isn-1_0_beta.20060924.tar.bzKronuz."Foolsrushinwherefoolshavebeenbefore"-Unknown Date: Tue, 22 Aug 2006 09:48:55 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module MichaelGlaesemannwrote: OnAug22,2006,at2:52,BruceMomjianwrote: Dowewanttoreplaceour/contrib/isbnwiththis,orhaveitpgfoundry? Ifcontrib/isbnismadeobsoletebythepgfoundryISBN/ISSN/ISMN/EAN13 code,unlessthere'sacompellingreasonthatthepgfoundrybepartof thedistribution,Irecommendremovingcontrib/isbnfromthecore distributionandpointingpeopletopgfoundry. AFAIKthereisnocodecurrentlyonpgfoundry.Wehadaproposedproject alittlewhilebackbuttheproposergotimpatientanddecidedto withdrawit. Ithinkthathavingthisorasimilarmoduleincontribhassome advantages,asanexampleonhowtodouserdefinedtypes,andasa checkthatpgxsisworkinginsuchcases. cheers andrewCall friends with PC-to-PC calling -- FREE Try it now! isn-1_0_beta.20060924.tar.bz Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Michael wrote: Idohopethatyouralgorithmforgenerating13digitsfrom10hasbeen validatedwithisbn.org,sinceallthecheckdigitswillchange.I believeitiscrucialforpostgresqltogenerateisbncodesinboth10 and13digits Indeed now that see the module it's finally close to be accepted as an official module, I'm verifying my algorithm against the one in the ISBN User Manual and all the current information I can get my hands into (I first created the module a couple years ago,and there wasn't as much information back then.) The module internally keeps all the numbers in EAN13 mode, and it only converts the numbers to ISBN when required or needed by the selected data type. andinthetwoseparatewaysrequiredofpublisherson theirbarcodes,withjustthe10digitinput.Thisisjustaspecial casefortheoverallclassificationsystem,sotheinitial3digitcode forbookpublishersshouldnotbehardwired. I got lost in what you said here, could you please be more specific? what is that about the initial 3 digit code you're mentioning? do you mean "the two separate ways", you meanboth ISBN and ISBN13as in: ISBN-13: 978-1-873671-00-9 ISBN-10: 1-873671-00-8 ? Shortly, I'll be further improving the performance and doing some tweaking in other areas, as well as updating the ISBN hyphenation ranges and probably adding UPC support.I'm still not sure if to include hyphenations in the EAN13 codes as it seems it's not part of the standard, thus 0036000291452 and 9781873671009 would be to examples of how the EAN13 numbers would show without hyphenation Thanks for your concerns, Kronuz. "Foolsrushinwherefoolshavebeenbefore"-UnknownGet the new Windows Live Messenger! Try it!
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Jeremy Kronuz wrote: Michael wrote: I do hope that your algorithm for generating 13 digits from 10 has been validated with isbn.org, since all the check digits will change. I believe it is crucial for postgresql to generate isbn codes in both 10 and 13 digits Indeed now that see the module it's finally close to be accepted as an official module, I'm verifying my algorithm against the one in the ISBN User Manual and all the current information I can get my hands into (I first created the module a couple years ago, and there wasn't as much information back then.) The module internally keeps all the numbers in EAN13 mode, and it only converts the numbers to ISBN when required or needed by the selected data type. and in the two separate ways required of publishers on their bar codes, with just the 10 digit input. This is just a special case for the overall classification system, so the initial 3 digit code for book publishers should not be hard wired. I got lost in what you said here, could you please be more specific? what is that about the initial 3 digit code you're mentioning? do you mean the two separate ways, you mean both ISBN and ISBN13 as in: ISBN-13: 978-1-873671-00-9 ISBN-10: 1-873671-00-8 ? Shortly, I'll be further improving the performance and doing some tweaking in other areas, as well as updating the ISBN hyphenation ranges and probably adding UPC support. I'm still not sure if to include hyphenations in the EAN13 codes as it seems it's not part of the standard, thus 0036000291452 and 9781873671009 would be to examples of how the EAN13 numbers would show without hyphenation Thanks for your concerns, Kronuz. Fools rush in where fools have been before - Unknown Get the new Windows Live Messenger! Try it! http://get.live.com/messenger/overview the 978 is the worldwide classification for book publishers. There is a complete schedule of 3 digit prefixes for all other types of products in the world, and it syncs withbthe NAIAC -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.5/425 - Release Date: 8/22/2006 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Michael Glaesemann wrote: On Aug 22, 2006, at 2:52 , Bruce Momjian wrote: Do we want to replace our /contrib/isbn with this, or have it pgfoundry? If contrib/isbn is made obsolete by the pgfoundry ISBN/ISSN/ISMN/EAN13 code, unless there's a compelling reason that the pgfoundry be part of the distribution, I recommend removing contrib/isbn from the core distribution and pointing people to pgfoundry. AFAIK there is no code currently on pgfoundry. We had a proposed project a little while back but the proposer got impatient and decided to withdraw it. I think that having this or a similar module in contrib has some advantages, as an example on how to do user defined types, and as a check that pgxs is working in such cases. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Do we want to replace our /contrib/isbn with this, or have it pgfoundry? --- Jeremy Kronuz wrote: I worked on this ISBN/ISSN/ISMN/EAN13 module about more than a year ago, and I was wondering if it could be made official, I honestly think it's better than the ISBN/ISSN currently included in the official release; plus mine would also probably support UPC codes and it already support the new ISBN13 codes. Check my old post: New ISBN/ISSN/ISMN/EAN13 module. at http://archives.postgresql.org/pgsql-hackers/2004-11/msg00153.php In that post I explain what the module does... I was also describing some problems I had, but the module it's working now. Please, share your thoughts. Kronuz. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Bruce Momjian wrote: Do we want to replace our /contrib/isbn with this, or have it pgfoundry? --- Jeremy Kronuz wrote: I worked on this ISBN/ISSN/ISMN/EAN13 module about more than a year ago, and I was wondering if it could be made official, I honestly think it's better than the ISBN/ISSN currently included in the official release; plus mine would also probably support UPC codes and it already support the new ISBN13 codes. Check my old post: New ISBN/ISSN/ISMN/EAN13 module. at http://archives.postgresql.org/pgsql-hackers/2004-11/msg00153.php In that post I explain what the module does... I was also describing some problems I had, but the module it's working now. Please, share your thoughts. Kronuz. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings As a publisher in the last throes of moving to 13 digits, I believe that this issue needs tgo be resolved before the ISBN deadline of January 2007. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.3/423 - Release Date: 8/18/2006 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
I suppose having it to replace the current contrib/isbn would be a good option, this 13 digits ISBN will be the standard by 2007, and some publishers are already issuing 13 digit ISBN numbers since last year. The module I created uses int64 instead of strings, for the numbers, and thus the performance might be better too, though I haven't tested for speed. Please, let me know if it will be included as a contrib, as I have updated the ISBN range numbersto include the most recent ones. Kronuz. From: [EMAIL PROTECTED] Subject: Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module To: [EMAIL PROTECTED] Date: Mon, 21 Aug 2006 13:52:26 -0400 CC: pgsql-hackers@postgresql.org Dowewanttoreplaceour/contrib/isbnwiththis,orhaveitpgfoundry? --- JeremyKronuzwrote: IworkedonthisISBN/ISSN/ISMN/EAN13moduleaboutmorethanayear ago,andIwaswonderingifitcouldbemadeofficial,Ihonestlythink it'sbetterthantheISBN/ISSNcurrentlyincludedintheofficial release;plusminewouldalsoprobablysupportUPCcodesanditalready supportthenewISBN13codes. Checkmyoldpost:"NewISBN/ISSN/ISMN/EAN13module."at http://archives.postgresql.org/pgsql-hackers/2004-11/msg00153.php InthatpostIexplainwhatthemoduledoes...Iwasalsodescribing someproblemsIhad,butthemoduleit'sworkingnow. Please,shareyourthoughts.Kronuz. _ ExpressyourselfinstantlywithMSNMessenger!Downloadtodayit's FREE!http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- BruceMomjian[EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com +Ifyourlifeisaharddrive,Christcanbeyourbackup.+Windows Live Spaces is here! It’s easy to create your own personal Web site. Check it out!
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
Jeremy Kronuz wrote: I suppose having it to replace the current contrib/isbn would be a good option, this 13 digits ISBN will be the standard by 2007, and some publishers are already issuing 13 digit ISBN numbers since last year. The module I created uses int64 instead of strings, for the numbers, and thus the performance might be better too, though I haven't tested for speed. Please, let me know if it will be included as a contrib, as I have updated the ISBN range numbers to include the most recent ones. I do hope that your algorithm for generating 13 digits from 10 has been validated with isbn.org, since all the check digits will change. I believe it is crucial for postgresql to generate isbn codes in both 10 and 13 digits, and in the two separate ways required of publishers on their bar codes, with just the 10 digit input. This is just a special case for the overall classification system, so the initial 3 digit code for book publishers should not be hard wired. (I know, as very competent engineers you have thought of all this, I am just being obsessive.) Incidentally, we are looking to publish manuscripts across a widerange of subject areas, so if anyone has anything not committed to the big names let me know. We are not a vanity publisher and our cotract provides for 20 percent royalties. We publish under the Cretive Commons License. Our newest book Chess for Bright Children of any age is forthcoming. We got the idea for the title from the New Testament. MIchael -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.3/423 - Release Date: 8/18/2006 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module
On Aug 22, 2006, at 2:52 , Bruce Momjian wrote: Do we want to replace our /contrib/isbn with this, or have it pgfoundry? If contrib/isbn is made obsolete by the pgfoundry ISBN/ISSN/ISMN/ EAN13 code, unless there's a compelling reason that the pgfoundry be part of the distribution, I recommend removing contrib/isbn from the core distribution and pointing people to pgfoundry. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] ISBN/ISSN/ISMN/EAN13 module
I worked on this ISBN/ISSN/ISMN/EAN13 module about more than a year ago, and I was wondering if it could be made official, I honestly think it's better than the ISBN/ISSN currently included in the official release; plus mine would also probably support UPC codes and it already support the new ISBN13 codes. Check my old post: "New ISBN/ISSN/ISMN/EAN13 module." at http://archives.postgresql.org/pgsql-hackers/2004-11/msg00153.php In that post I explain what the module does... I was also describingsome problems I had, but the module it's working now. Please, share your thoughts. Kronuz. Express yourself instantly with MSN Messenger! MSN Messenger
