Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

[Jeremy Kronuz]

> 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

Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

[Jeremy Kronuz]

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

[Tom Lane]

"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

[Tom Lane]

"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 
> that’s 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]

"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 
that’s 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

[Bruce Momjian]

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, Germn Mndez 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

[Tom Lane]

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

[Bruce Momjian]

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

[Tom Lane]

"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

[Bruce Momjian]

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

[Jeremy Kronuz]

Hello again,This is an usable version of my EAN13/UPC/ISBN module. 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 server it'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.bz Kronuz."Fools rush in where fools have been before" - 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> > 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> > 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

[Jeremy Kronuz]

>
> >  > > > 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> >> >> > 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> 
Okay, I've finally finished something usable.
I'm attaching the source code in a .tgz, it should go inside the contrib 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.
"Fools rush in where fools have been before" - 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

[mdean]

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! 



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

[Jeremy Kronuz]

 
> 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" - UnknownGet the new Windows Live Messenger! Try it!

Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

[Andrew Dunstan]

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

[Michael Glaesemann]

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

Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

[mdean]

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

[Jeremy Kronuz]

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.
 
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> > > 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. +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

[mdean]

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

[Bruce Momjian]

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