Thread: ISBN/ISSN/ISMN/EAN13 module

<p>I worked on this ISBN/ISSN/<font class="">ISMN</font>/<font class="">EAN13</font> module about more than a y<font
class="">ear</font>ago, and I was wondering if it could be made official, I honestly think it's better than the
ISBN/ISSNcurrently included in the official release; plus mine would also probably support <font class="">UPC</font>
codesand it already support the new <font class="">ISBN13</font> codes.<p> <p>Check my old post: "New ISBN/ISSN/<font
class="">ISMN</font>/<fontclass="">EAN13</font> module." at <a
href="http://archives.postgresql.org/pgsql-hackers/2004-11/msg00153.php">http://archives.postgresql.org/pgsql-hackers/2004-11/msg00153.php</a><p> <p>In
thatpost I explain what the module does... I was also describing some problems I had, but the module it's working
now.<p> <p>Please,share your thoughts.<p><font class="">Kronuz</font>.<p> <br /><hr />Express yourself instantly with
MSNMessenger! <a href="http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/" target="_new">MSN Messenger</a> 

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   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

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   bruce@momjian.us
>  EnterpriseDB    http://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

I suppose having it to replace the current contrib/isbn would be a good option, this 13 digits ISBN will be the
standardby 2007, and some publishers are already issuing 13 digit ISBN numbers since last year.<br />  <br /> The
moduleI created uses int64 instead of strings, for the numbers, and thus the performance might be better too, though I
haven'ttested for speed.<br /> Please, let me know if it will be included as a contrib, as I have updated the ISBN
rangenumbers to include the most recent ones.<br />  <br /> Kronuz.<br />  <br /> > From: bruce@momjian.us<br />>
Subject:Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module<br />> To: kronuz@hotmail.com<br />> Date: Mon, 21 Aug 2006
13:52:26-0400<br />> CC: pgsql-hackers@postgresql.org<br />> <br />> <br />>
Do we want to replace our /contrib/isbn with this, or have it pgfoundry?<br/>> <br />>
---------------------------------------------------------------------------<br/>> <br />> Jeremy Kronuz wrote:<br
/>>> I worked on this ISBN/ISSN/ISMN/EAN13 module about more than a year<br />>
> ago, and I was wondering if it could be made official, I honestly think<br/>>
> it's better than the ISBN/ISSN currently included in the official<br/>>
> release; plus mine would also probably support UPC codes and it already<br/>>
> support the new ISBN13 codes.<br/>> > <br />>
> Check my old post: "New ISBN/ISSN/ISMN/EAN13 module." at<br/>>
> http://archives.postgresql.org/pgsql-hackers/2004-11/msg00153.php<br/>> > <br />>
> In that post I explain what the module does... I was also describing<br/>>
> some problems I had, but the module it's working now.<br/>> > <br />>
> Please, share your thoughts.  Kronuz.<br/>> > <br />>
> _________________________________________________________________<br/>>
> Express yourself instantly with MSN Messenger! Download today it's<br/>>
> FREE!  http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/<br/>> --<br />>
  Bruce Momjian   bruce@momjian.us<br/>>   EnterpriseDB    http://www.enterprisedb.com<br />> <br />>
  + If your life is a hard drive, Christ can be your backup. +<br/><br /><br /><hr />Windows Live Spaces is here! It’s
easyto create your own personal Web site. <a href="http://spaces.live.com/signup.aspx" target="_new">Check it out!</a> 

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

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

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

 <br /> > Michael wrote:<br />> I do hope that your algorithm for generating 13 digits from 10 has been <br
/>>validated with <font><font>isbn.org</font></font>, since all the check digits will change.  I <br />>
believe it is crucial for postgresql to generate isbn codes in both 10 <br/>> and 13 digits<br /><br /> Indeed now
thatsee the module it's finally close to be accepted as an official module, I'm verifying my algorithm against the one
inthe ISBN User Manual and all the current information I can get my hands into (I first created the module a couple
yearsago, and there wasn't as much information back then.)<br />  <br /> The module internally keeps all the numbers in
EAN13mode, and it only converts the numbers to ISBN when required or needed by the selected data type.<br />  <br />
>and in the two separate ways required of publishers on <br />>
their bar codes, with just the 10 digit input.  This is just a special <br/>>
case for the overall classification system, so the initial 3 digit code <br/>>
for book publishers should not be hard wired. <br/>  <br /> 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?<br /> do you mean "the two separate ways", you
mean bothISBN and ISBN13 as in:<br /><font face="Arial"><p align="left">  ISBN-13: 978-1-873671-00-9<p align="left"> 
ISBN-10:1-873671-00-8</font> ?<br />  <br /> Shortly, I'll be further improving the performance and doing some tweaking
inother areas, as well as updating the ISBN hyphenation ranges and probably adding UPC support.<br />I'm still not sure
ifto include hyphenations in the EAN13 codes as it seems it's not part of the standard, thus 0036000291452 and
9781873671009would be to examples of how the <font>EAN13 numbers would show without hyphenation....</font><br />  <br
/>Thanks for your concerns,<br /> Kronuz.<br /><br />"Fools rush in where fools have been before" - Unknown<br /><br
/><br/><hr />Get the new Windows Live Messenger! <a href="http://get.live.com/messenger/overview" target="_new">Try
it!</a>

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

>
> >  
> > > 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!

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.

---

Call friends with PC-to-PC calling -- FREE Try it now!

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   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

"Jeremy Kronuz" <kronuz@hotmail.com> 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

Tom Lane wrote:
> "Jeremy Kronuz" <kronuz@hotmail.com> 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   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> 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

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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, Germ<E1>n M<E9>ndez 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   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

>
>"Jeremy Kronuz" <kronuz@hotmail.com> 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.

"Jeremy Kronuz" <kronuz@hotmail.com> 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

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

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.c    2006-09-08 23:07:52.000000000 -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(9999999999999))
+        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' */
+
+    /* find out the data type: */
+    if(!strncmp("978", buf, 3)) { /* ISBN */
+        type = ISBN;
+    } else if(!strncmp("977", buf, 3)) { /* ISSN */
+        type = ISSN;
+    } else if(!strncmp("9790", buf, 4)) { /* ISMN */
+        type = ISMN;
+    } else if(!strncmp("979", buf, 3)) { /* ISBN-13 */
+        type = ISBN;
+    } else if(*buf == '0') { /* UPC */
+        type = UPC;
+    } else {
+        type = EAN13;
+    }
+    if(accept != ANY && accept != EAN13 && accept != type) goto eanwrongtype;
+
+    *result = ret;
+    return true;
+
+eanwrongtype:
+    if(!errorOK) {
+        if(type!=EAN13) {
+            ereport(ERROR,
+                (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+                 errmsg("cannot cast EAN13(%s) to %s for number: \"%s\"",
+                        isn_names[type], isn_names[accept], buf)));
+        } else {
+            ereport(ERROR,
+                (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+                 errmsg("cannot cast %s to %s for number: \"%s\"",
+                        isn_names[type], isn_names[accept], buf)));
+        }
+    }
+    return false;
+
+eantoobig:
+    if(!errorOK) {
+        char    eanbuf[64];
+
+        /*
+         * Format the number separately to keep the machine-dependent
+         * format code out of the translatable message text
+         */
+        snprintf(eanbuf, sizeof(eanbuf), EAN13_FORMAT, ean);
+        ereport(ERROR,
+                (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
+                 errmsg("value \"%s\" is out of range for %s type",
+                        eanbuf, isn_names[type])));
+    }
+    return false;
+}
+
+/*
+ * ean2UPC/ISxN --- Convert in-place a normalized EAN13 string to the
corresponding
+ *                  UPC/ISxN string number. Assumes the input string is
normalized.
  */
static inline
void ean2ISBN(char *isn)
@@ -325,7 +411,8 @@
{
    ean13 ean = 0;    /* current ean */
    while(*num) {
-        ean = 10 * ean + ((*num++) - '0');
+        if(isdigit(*num)) ean = 10 * ean + (*num - '0');
+        num++;
    }
     return (ean<<1); /* also give room to a flag */
}
@@ -336,7 +423,7 @@
  *                the string (maximum MAXEAN13LEN+1 bytes)
  *                This doesn't verify for a valid check digit.
  *
- * If shortType is true, the returned string is in the old ISN short
format.
+ * If shortType is true, the returned string is in the old ISxN short
format.
  * If errorOK is false, ereport a useful error message if the string is
bad.
  * If errorOK is true, just return "false" for bad input.
  */
@@ -369,8 +456,8 @@
        digval = (unsigned)(ean % 10);        /* get the decimal value */
        ean /= 10;                                                /* get next digit */
        *--aux = (char)(digval + '0');            /* convert to ascii and store */
-        if(++search == 1) *--aux = '-';            /* the check digit is always there */
-    } while(ean);
+        if(search == 0) *--aux = '-';            /* the check digit is always there */
+    } while(ean && search++<13);
    while(search++<13) *--aux = '0';            /* fill the remaining EAN13 with '0' */

    /* The string should be in this form: ???DDDDDDDDDDDD-D" */
@@ -409,7 +496,7 @@
        TABLE_index = NULL;
    }

-    /* verify it's a logically valid EAN13/ISN */
+    /* verify it's a logically valid EAN13/UPC/ISxN */
    digval = search;
    search = hyphenate(result+digval, result+digval+2, TABLE, TABLE_index);

@@ -452,8 +539,8 @@
        snprintf(eanbuf, sizeof(eanbuf), EAN13_FORMAT, ean);
        ereport(ERROR,
                (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
-                 errmsg("value \"%s\" is out of range for ISN type",
-                        eanbuf)));
+                 errmsg("value \"%s\" is out of range for %s type",
+                        eanbuf, isn_names[type])));
    }
    return false;
}
@@ -483,7 +570,7 @@
    /* recognize and validate the number: */
    while(*aux2 && length <= 13) {
        last = (*(aux2+1) == '!' || *(aux2+1) == '\0'); /* is the last character
*/
-        digit = isdigit(*aux2); /* is current character a digit? */
+        digit = (isdigit(*aux2)!=0); /* is current character a digit? */
        if(*aux2=='?' && last) /* automagically calculate check digit if it's '?'
*/
            magic = digit = true;
        if(length == 0 &&  (*aux2=='M' || *aux2=='m')) {
@@ -583,19 +670,25 @@
            break;
    }

-    if(!valid && !magic) goto eanbadcheck;
-
+  /* fix the check digit: */
    for(aux1 = buf; *aux1 && *aux1 <= ' '; aux1++);
    aux1[12] = checkdig(aux1, 13) + '0';
    aux1[13] = '\0';

+    if(!valid && !magic) goto eanbadcheck;
+
    *result = str2ean(aux1);
    *result |= valid?0:1;
-
    return true;

eanbadcheck:
-    if(!g_weak) {
+    if(g_weak) { /* weak input mode is activated: */
+      /* set the "invalid-check-digit-on-input" flag */
+        *result = str2ean(aux1);
+        *result |= 1;
+    return true;
+    }
+
        if(!errorOK) {
            if(rcheck == (unsigned)-1) {
                ereport(ERROR,
@@ -610,30 +703,6 @@
            }
        }
        return false;
-    }
-
-    if(accept != EAN13 && accept != ANY && type != accept) goto eanwrongtype;
-
-    /* fix the check digit: */
-    for(aux1 = buf; *aux1 && *aux1 <= ' '; aux1++);
-    aux1[12] = checkdig(aux1, 13) + '0';
-    aux1[13] = '\0';
-    *result = str2ean(aux1);
-
-     /* set the "invalid-check-digit-on-input" flag */
-    *result |= 1;
-
-    /* just warn about the error when there was a real check digit error: */
-    if(check != rcheck) {
-        if(rcheck == (unsigned)-1) {
-            elog(WARNING, "invalid %s number: \"%s\"",
-                isn_names[accept], str);
-        } else {
-            elog(WARNING, "invalid check digit for %s number: \"%s\", should be %c",
-                isn_names[accept], str, (rcheck==10)?('X'):(rcheck+'0'));
-        }
-    }
-    return true;

eaninvalid:
    if(!errorOK)
@@ -647,8 +716,8 @@
    if(!errorOK)
        ereport(ERROR,
                (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
-                 errmsg("invalid %s type for number: \"%s\"",
-                        isn_names[accept], str)));
+                 errmsg("cannot cast %s to %s for number: \"%s\"",
+                        isn_names[type], isn_names[accept], str)));
    return false;

eantoobig:
@@ -784,26 +853,97 @@
Datum
ean13_cast_to_text(PG_FUNCTION_ARGS)
{
-    ean13        val = PG_GETARG_EAN13(0);
-    char        buf[MAXEAN13LEN + 1];
+    /* arg is ean13, but easier to leave it as Datum */
+    Datum        arg = PG_GETARG_DATUM(0);
+    char       *s;
+    int            len;
+    text       *result;

-    (void) ean2string(val, false, buf, false);
+    s = DatumGetCString(DirectFunctionCall1(ean13_out, arg));
+    len = strlen(s);
+
+    result = (text *) palloc(VARHDRSZ + len);

-    PG_RETURN_TEXT_P(GET_TEXT(buf));
+    VARATT_SIZEP(result) = len + VARHDRSZ;
+    memcpy(VARDATA(result), s, len);
+
+    pfree(s);
+
+    PG_RETURN_TEXT_P(result);
}

PG_FUNCTION_INFO_V1(isn_cast_to_text);
Datum
isn_cast_to_text(PG_FUNCTION_ARGS)
{
+    /* arg is ean13, but easier to leave it as Datum */
+    Datum        arg = PG_GETARG_DATUM(0);
+    char       *s;
+    int            len;
+    text       *result;
+
+    s = DatumGetCString(DirectFunctionCall1(isn_out, arg));
+    len = strlen(s);
+
+    result = (text *) palloc(VARHDRSZ + len);
+
+    VARATT_SIZEP(result) = len + VARHDRSZ;
+    memcpy(VARDATA(result), s, len);
+
+    pfree(s);
+
+    PG_RETURN_TEXT_P(result);
+}
+
+PG_FUNCTION_INFO_V1(isbn_cast_from_ean13);
+Datum
+isbn_cast_from_ean13(PG_FUNCTION_ARGS)
+{
    ean13        val = PG_GETARG_EAN13(0);
-    char        buf[MAXEAN13LEN + 1];
+    ean13        result;

-    (void) ean2string(val, false, buf, true);
+    (void) ean2isn(val, false, &result, ISBN);
+
+    PG_RETURN_EAN13(result);
+}
+
+PG_FUNCTION_INFO_V1(ismn_cast_from_ean13);
+Datum
+ismn_cast_from_ean13(PG_FUNCTION_ARGS)
+{
+    ean13        val = PG_GETARG_EAN13(0);
+    ean13        result;

-    PG_RETURN_TEXT_P(GET_TEXT(buf));
+    (void) ean2isn(val, false, &result, ISMN);
+
+    PG_RETURN_EAN13(result);
}

+PG_FUNCTION_INFO_V1(issn_cast_from_ean13);
+Datum
+issn_cast_from_ean13(PG_FUNCTION_ARGS)
+{
+    ean13        val = PG_GETARG_EAN13(0);
+    ean13        result;
+
+    (void) ean2isn(val, false, &result, ISSN);
+
+    PG_RETURN_EAN13(result);
+}
+
+PG_FUNCTION_INFO_V1(upc_cast_from_ean13);
+Datum
+upc_cast_from_ean13(PG_FUNCTION_ARGS)
+{
+    ean13        val = PG_GETARG_EAN13(0);
+    ean13        result;
+
+    (void) ean2isn(val, false, &result, UPC);
+
+    PG_RETURN_EAN13(result);
+}
+
+
PG_FUNCTION_INFO_V1(ean13_cast_from_text);
Datum
ean13_cast_from_text(PG_FUNCTION_ARGS)
diff -ruN oldisn/isn.h isn/isn.h
--- oldisn/isn.h    2006-09-08 23:07:52.000000000 -0500
+++ isn/isn.h    2006-09-09 16:35:49.486379700 -0500
@@ -27,8 +27,8 @@

#define EAN13_FORMAT UINT64_FORMAT

-#define PG_GETARG_EAN13(n) PG_GETARG_INT64(n)
-#define PG_RETURN_EAN13(x) PG_RETURN_INT64(x)
+#define PG_GETARG_EAN13(n) PG_GETARG_INT64((int64)n)
+#define PG_RETURN_EAN13(x) PG_RETURN_INT64((int64)x)

extern Datum isn_out(PG_FUNCTION_ARGS);
extern Datum ean13_out(PG_FUNCTION_ARGS);
@@ -45,6 +45,10 @@
extern Datum ismn_cast_from_text(PG_FUNCTION_ARGS);
extern Datum issn_cast_from_text(PG_FUNCTION_ARGS);
extern Datum upc_cast_from_text(PG_FUNCTION_ARGS);
+extern Datum isbn_cast_from_ean13(PG_FUNCTION_ARGS);
+extern Datum ismn_cast_from_ean13(PG_FUNCTION_ARGS);
+extern Datum issn_cast_from_ean13(PG_FUNCTION_ARGS);
+extern Datum upc_cast_from_ean13(PG_FUNCTION_ARGS);

extern Datum is_valid(PG_FUNCTION_ARGS);
extern Datum make_valid(PG_FUNCTION_ARGS);
diff -ruN oldisn/isn.sql.in isn/isn.sql.in
--- oldisn/isn.sql.in    2006-09-08 23:07:52.000000000 -0500
+++ isn/isn.sql.in    2006-09-09 16:03:53.771250000 -0500
@@ -2131,86 +2131,111 @@
-- Type casts:
--
---------------------------------------------------
+CREATE FUNCTION isbn13(ean13)
+RETURNS isbn13
+AS 'MODULE_PATHNAME', 'isbn_cast_from_ean13'
+LANGUAGE 'C' IMMUTABLE STRICT;
+CREATE FUNCTION ismn13(ean13)
+RETURNS ismn13
+AS 'MODULE_PATHNAME', 'ismn_cast_from_ean13'
+LANGUAGE 'C' IMMUTABLE STRICT;
+CREATE FUNCTION issn13(ean13)
+RETURNS issn13
+AS 'MODULE_PATHNAME', 'issn_cast_from_ean13'
+LANGUAGE 'C' IMMUTABLE STRICT;
+CREATE FUNCTION isbn(ean13)
+RETURNS isbn
+AS 'MODULE_PATHNAME', 'isbn_cast_from_ean13'
+LANGUAGE 'C' IMMUTABLE STRICT;
+CREATE FUNCTION ismn(ean13)
+RETURNS ismn
+AS 'MODULE_PATHNAME', 'ismn_cast_from_ean13'
+LANGUAGE 'C' IMMUTABLE STRICT;
+CREATE FUNCTION issn(ean13)
+RETURNS issn
+AS 'MODULE_PATHNAME', 'issn_cast_from_ean13'
+LANGUAGE 'C' IMMUTABLE STRICT;
+CREATE FUNCTION upc(ean13)
+RETURNS upc
+AS 'MODULE_PATHNAME', 'upc_cast_from_ean13'
+LANGUAGE 'C' IMMUTABLE STRICT;
+
+
CREATE FUNCTION ean13(text)
RETURNS ean13
AS 'MODULE_PATHNAME', 'ean13_cast_from_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION isbn13(text)
RETURNS isbn13
AS 'MODULE_PATHNAME', 'isbn_cast_from_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION ismn13(text)
RETURNS ismn13
AS 'MODULE_PATHNAME', 'ismn_cast_from_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION issn13(text)
RETURNS issn13
AS 'MODULE_PATHNAME', 'issn_cast_from_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION isbn(text)
RETURNS isbn
AS 'MODULE_PATHNAME', 'isbn_cast_from_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION ismn(text)
RETURNS ismn
AS 'MODULE_PATHNAME', 'ismn_cast_from_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION issn(text)
RETURNS issn
AS 'MODULE_PATHNAME', 'issn_cast_from_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION upc(text)
RETURNS upc
AS 'MODULE_PATHNAME', 'upc_cast_from_text'
LANGUAGE 'C' IMMUTABLE STRICT;

+
CREATE FUNCTION text(ean13)
RETURNS text
AS 'MODULE_PATHNAME', 'ean13_cast_to_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION text(isbn13)
RETURNS text
AS 'MODULE_PATHNAME', 'ean13_cast_to_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION text(ismn13)
RETURNS text
AS 'MODULE_PATHNAME', 'ean13_cast_to_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION text(issn13)
RETURNS text
AS 'MODULE_PATHNAME', 'ean13_cast_to_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION text(isbn)
RETURNS text
AS 'MODULE_PATHNAME', 'isn_cast_to_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION text(ismn)
RETURNS text
AS 'MODULE_PATHNAME', 'isn_cast_to_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION text(issn)
RETURNS text
AS 'MODULE_PATHNAME', 'isn_cast_to_text'
LANGUAGE 'C' IMMUTABLE STRICT;
-
CREATE FUNCTION text(upc)
RETURNS text
AS 'MODULE_PATHNAME', 'isn_cast_to_text'
LANGUAGE 'C' IMMUTABLE STRICT;

+CREATE CAST (ean13 AS isbn13) WITH FUNCTION isbn13(ean13);
+CREATE CAST (ean13 AS isbn) WITH FUNCTION isbn(ean13);
+CREATE CAST (ean13 AS ismn13) WITH FUNCTION ismn13(ean13);
+CREATE CAST (ean13 AS ismn) WITH FUNCTION ismn(ean13);
+CREATE CAST (ean13 AS issn13) WITH FUNCTION issn13(ean13);
+CREATE CAST (ean13 AS issn) WITH FUNCTION issn(ean13);
+CREATE CAST (ean13 AS upc) WITH FUNCTION upc(ean13);
+
CREATE CAST (isbn13 AS ean13) WITHOUT FUNCTION AS ASSIGNMENT;
CREATE CAST (isbn AS ean13) WITHOUT FUNCTION AS ASSIGNMENT;
CREATE CAST (ismn13 AS ean13) WITHOUT FUNCTION AS ASSIGNMENT;
@@ -2218,6 +2243,7 @@
CREATE CAST (issn13 AS ean13) WITHOUT FUNCTION AS ASSIGNMENT;
CREATE CAST (issn AS ean13) WITHOUT FUNCTION AS ASSIGNMENT;
CREATE CAST (upc AS ean13) WITHOUT FUNCTION AS ASSIGNMENT;
+
CREATE CAST (isbn AS isbn13) WITHOUT FUNCTION AS ASSIGNMENT;
CREATE CAST (isbn13 AS isbn) WITHOUT FUNCTION AS ASSIGNMENT;
CREATE CAST (ismn AS ismn13) WITHOUT FUNCTION AS ASSIGNMENT;

"Jeremy Kronuz" <kronuz@hotmail.com> 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

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

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

"Jeremy Kronuz" <kronuz@hotmail.com> writes:
> ... 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.)

Um, no, doesn't work at all unfortunately:

$ patch --dry <~/ean.patch
patching file isn.c
patch: **** malformed patch at line 6: enum isn_type { INVALID, ANY, EAN13, ISBN, ISMN, ISSN, UPC };

$

It looks like the patch got whitespace-mangled in transit.  With many
mail programs it works better to add a patch as an attachment than
to try to include it directly in the message text.  Also, we usually
ask for diff -c rather than diff -u format ... I for one find it easier
to read.

Please sync the text-conversion issues and resubmit.

            regards, tom lane