Thread

1. Re: Cosmetic bug in 7.0 docs

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-05-01T11:22:08Z

   >  I today a save time for reading in current docs  (it is under next URL?)
   >         http://www.postgresql.org/docs/postgres/index.html
   >  and I found some cosmetic bugs:
   >  - the copyright is 1996-9, but not 2000 (is it right?)
   
   Fixed that in my sources while generating hardcopy; will commit today.
   
   >  - the pg_dump support long argv switches (like the other routines), but
   >         in docs it is not.
   
   Sorry, where exactly is that in the docs? I haven't looked yet, but
   will poke at pg_dump.sgml...
   
                       - Thomas
   
   -- 
   Thomas Lockhart				lockhart@alumni.caltech.edu
   South Pasadena, California
   
   

2. Re: Case insensitive collation.

   Malcontent null <malcontent@msgto.com> — 2000-05-02T05:22:09Z

   If this is not the right place to ask this question please feel free to
   tell me to go away but I figure you guys would know the code best.
   
   In a nutshell I want to use postgres as a back end to an access
   database. This means that all collation done by postgres musht be case
   insensitive including like clauses. Combing through the archives I
   noticed that this question has been asked many times and the answer
   seems to be to use *~ or to use lower(something)=lower(something).
   Unfrotunately neither of these will work with access because access will
   be generating the query in response to some user setting a filter or
   pressing a button.
   
   From my research I gather that I have one of two options here. One is to
   overload the = and the ~~ operators using a user defined function or to
   just go at the source itself and change the text_cmp in varlena.c and/or
   varchareq function in varchar.c.
   
   If I overload the function using pl/pqsql how much of a performance hit
   am I taking? If I decide to rewrite the comparison functions will I
   break everything and if not which other functions should I rewrite.
   
   Also how much damage will I do if I change the NAMEDATALEN to come a
   little closer to access standards (actually I was thinking of setting it
   something like 64 as a compromise).