Converted pgcrypto one too.
* Changed default randomness source to libc random()
That way pgcrypto does not have any external dependencies
and should work everywhere.
* Re-enabled pgcrypto build in contrib/makefile
* contrib/README update - there is more stuff than
only 'hash functions'
* Noted the libc random fact in README.pgcrypto
Marko Kreen
be able to apply against what you just committed. It rolls soundex into
fuzzystrmatch.
Remove soundex/metaphone and merge into fuzzystrmatch.
Joe Conway
metaphone() in a contrib. There seem to be a fair number of different
approaches to both of these algorithms. I used the simplest case for
levenshtein which has a cost of 1 for any character insertion, deletion, or
substitution. For metaphone, I adapted the same code from CPAN that the PHP
folks did.
A couple of questions:
1. Does it make sense to fold the soundex contrib together with this one?
2. I was debating trying to add multibyte support to levenshtein (it would
make no sense at all for metaphone), but a quick search through the contrib
directory found no hits on the word MULTIBYTE. Should worry about adding
multibyte support to levenshtein()?
Joe Conway
a PostgreSQL user-defined function. The Metaphone system is a method of
matching similar sounding names (or any words) to the same code.
Metaphone was invented by Lawrence Philips as an improvement to the popular
name-hashing routine, Soundex.
This metaphone code is from Michael Kuhn, and is detailed at
http://aspell.sourceforge.net/metaphone/metaphone-kuhn.txt
Joel Burton
version number from the current database, and couldn't find any existing
program to do that.
linda:~$ pg_controldata
Log file id: 0
Log file segment: 5
Last modified: Wed Feb 7 19:35:47 2001
Database block size: 8192
Blocks per segment of large relation: 131072
Catalog version number: 200101061
LC_COLLATE: en_GB
LC_CTYPE: en_GB
Log archive directory:
Oliver Elphick Oliver.Elphick@lfix.co.uk
prepared for dirtribution (it needs a little changes). I can change and work
on this, but I need motivation :-)
And Peter, I know and I agree that standard PG tree is not good space for
all interfaces and for all tools based on PG, but LO is PG feature and we
haven't backup tool for LO.
Karel Zak
family functions. Contain:
conversion from a datetype to formatted text:
to_char( datetime, text)
to_char( timestamp, text)
to_char( int4, text)
to_char( int8, text)
to_char( float4, text)
to_char( float8, text)
to_char( numeric, text)
vice versa:
to_date ( text, text)
to_datetime ( text, text)
to_timestamp ( text, text)
to_number ( text, text) (convert to numeric)
PostgreSQL to_char is very compatible with Oracle's to_char(), but not
total exactly (now). Small differentions are in number formating. It will
fix in next to_char() version.
! If will this patch aplly to the main tree, must be delete the current
to_char version in contrib (directory "dateformat" and note in contrib's
README), this patch not erase it (sorry Bruce).
The patch patching files:
doc/src/sgml/func.sgml
^^^^^^^^
Hmm, I'm not sure if my English... :( Check it anyone (volunteer)?
Thomas, it is right? SGML is not my primary lang and compile
the current PG docs tree is very happy job (hard variables setting in
docs/sgml/Makefile --> HSTYLE= /home/users/t/thomas/.... :-)
What add any definition to global configure.in and set Makefiles in docs
tree via ./configure?
src/backend/utils/adt/Makefile
src/backend/utils/adt/formatting.c
src/include/catalog/pg_proc.h
src/include/utils/formatting.h
Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/
TO_DATE()
and PgSQL extension FROM_CHAR().
TO_CHAR() routine allow formating text output with a datetime values:
SELECT TO_CHAR('now'::datetime, '"Now is: "HH24:MI:SS');
to_char
----------------
Now is: 21:04:10
FROM_CHAR() routine allow convert text to a datetime:
SELECT FROM_CHAR('September 1999 10:20:30', 'FMMonth YYYY
HH:MI:SS');
from_char
-----------------------------
Wed Sep 01 10:20:30 1999 CEST
TO_DATE() is equal with FROM_CHAR(), but output a Date only:
SELECT TO_DATE('September 1999 10:20:30', 'FMMonth YYYY
HH:MI:SS');
to_date
----------
09-01-1999
In attache is compressed dir for the contrib. All is prepared, but I'am
not
sure if Makefile is good (probably yes).
Comments & suggestions ?
Thomas, thank you for your good advices.
Karel
------------------------------------------------------------------------------
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
test isn't that complete up to now, but I think it shows
enough of the capabilities of the module.
The Makefile assumes it is located in a directory under
pgsql/src/pl. Since it includes Makefile.global and
Makefile.port and doesn't use any own compiler/linker calls,
it should build on most of our supported platforms (I only
tested under Linux up to now). It requires flex and bison I
think. Maybe we should ship prepared gram.c etc. like for the
main parser too?
Jan
I do not know about these contributions well as I only made the binaries
to contribute to a Japanese Linux package.(I did not test them.) But I
try to make some brief introduction about the contrib directory with my
poor English. Here is a draft of README about contrib directory:
Tom Lane