- 14 7月, 2005 4 次提交
- 13 7月, 2005 10 次提交
-
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
freeing all transient state of the PGconn object.
-
由 Bruce Momjian 提交于
section of a function.
-
由 Bruce Momjian 提交于
treated as regex groups.
-
由 Bruce Momjian 提交于
I wrote: > So either we code up some intelligence to put the "C" in the right > position or we have to pass down "A B" and "D" separately from the > main makefile. The following patch might just do the former. Please try it out. Peter E.
-
由 Neil Conway 提交于
various editorialization from Neil Conway.
-
由 Tom Lane 提交于
gcc and for HP's ld on HPUX. There may be better ways to do this, but this seems to work for me...
-
由 Tom Lane 提交于
Reported by Michael Fuhr, fixed by Andrew Dunstan.
-
由 Tom Lane 提交于
compiler warnings. Marko Kreen and Kris Jurka.
-
由 Bruce Momjian 提交于
Blank line adjustments.
-
- 12 7月, 2005 4 次提交
-
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
Add suitable regression tests. Andrew Dunstan
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
Marko Kreen
-
- 11 7月, 2005 9 次提交
-
-
由 Tom Lane 提交于
Marko Kreen
-
由 Tom Lane 提交于
be more wary about having a value for BYTE_ORDER, clean up randomly- chosen ways of including Postgres core headers. Marko Kreen and Tom Lane
-
由 Tom Lane 提交于
Marko Kreen
-
由 Tom Lane 提交于
(harmless, actually, but let's be tidy).
-
由 Tom Lane 提交于
optional arguments as text input functions, ie, typioparam OID and atttypmod. Make all the datatypes that use typmod enforce it the same way in typreceive as they do in typinput. This fixes a problem with failure to enforce length restrictions during COPY FROM BINARY.
-
由 Bruce Momjian 提交于
> > I think this is because we don't have -lz in SHLIB_LINK. > Following patch fixes it. Marko Kreen
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
Add missing plperl include.
-
- 10 7月, 2005 13 次提交
-
-
由 Bruce Momjian 提交于
that don't have pg_malloc.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
Marko Kreen
-
由 Bruce Momjian 提交于
return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
-
由 Bruce Momjian 提交于
for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
-
由 Bruce Momjian 提交于
The Problem: Occassionally a DBA needs to dump a database to a new encoding. In instances where the current encoding, (or lack of an encoding, like SQL_ASCII) is poorly supported on the target database server, it can be useful to dump into a particular encoding. But, currently the only way to set the encoding of a pg_dump file is to change client_encoding in postgresql.conf and restart postmaster. This is more than a little awkward for production systems. Magnus Hagander
-
由 Bruce Momjian 提交于
into pg_catalog rather than public, and supports dumping languages whose handlers are found there. This will make it easier to drop the public schema if desired. Unlike the previous patch, the comments have been updated and I have reformatted some code to meet Alvarro's request to stick to 80 cols. (I actually aghree with this - it makes printing the code much nicer). I think I did the right thing w.r.t versions earlier than 7.3, but I have no real way of checking, so that should be checked by someone with more/older knowledge than me ;-) Andrew Dunstan
-
由 Bruce Momjian 提交于
OpenSSL 0.9.6x. The DES functions use the older 'des_' API, but the newer 3DES functions use the 0.9.7x-only 'DES_' API. I think I just used /usr/include/openssl/des.h for reference when implementing them, and had upgraded OpenSSL in the meantime. Following patch converts DES also to newer API and provides compatibility functions for OpenSSL < 0.9.7. I chose this route because: - openssl.c uses few DES functions. - compatibility for old 'des_' API is going away at some point of time from OpenSSL. - as seen from macros, new API is saner - Thus pgcrypto supports any OpenSSL version from 0.9.5 to 1.0 Tested with OpenSSL 0.9.6c and 0.9.7e. Marko Kreen
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
< computations should adjust based on the time zone rules, e.g. < adding 24 hours to a timestamp would yield a different result from < adding one day. < > computations should adjust based on the time zone rules.
-
由 Bruce Momjian 提交于
when a plpython function returns unicode" thread: http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php In several places PL/Python was calling PyObject_Str() and then PyString_AsString() without checking if the former had returned NULL to indicate an error. PyString_AsString() doesn't expect a NULL argument, so passing one causes a segmentation fault. This patch adds checks for NULL and raises errors via PLy_elog(), which prints details of the underlying Python exception. The patch also adds regression tests for these checks. All tests pass on my Solaris 9 box running HEAD and Python 2.4.1. In one place the patch doesn't call PLy_elog() because that could cause infinite recursion; see the comment I added. I'm not sure how to test that particular case or whether it's even possible to get an error there: the value that the code should check is the Python exception type, so I wonder if a NULL value "shouldn't happen." This patch converts NULL to "Unknown Exception" but I wonder if an Assert() would be appropriate. The patch is against HEAD but the same changes should be applied to earlier versions because they have the same problem. The patch might not apply cleanly against earlier versions -- will the committer take care of little differences or should I submit different versions of the patch? Michael Fuhr
-
由 Bruce Momjian 提交于
The specification of this function is as follows. regexp_replace(source text, pattern text, replacement text, [flags text]) returns text Replace string that matches to regular expression in source text to replacement text. - pattern is regular expression pattern. - replacement is replace string that can use '\1'-'\9', and '\&'. '\1'-'\9': back reference to the n'th subexpression. '\&' : entire matched string. - flags can use the following values: g: global (replace all) i: ignore case When the flags is not specified, case sensitive, replace the first instance only. Atsushi Ogawa
-
由 Bruce Momjian 提交于
of password-based encryption from RFC2440 (OpenPGP). The goal of this code is to be more featureful encryption solution than current encrypt(), which only functionality is running cipher over data. Compared to encrypt(), pgp_encrypt() does following: * It uses the equvialent of random Inital Vector to get cipher into random state before it processes user data * Stores SHA-1 of the data into result so any modification will be detected. * Remembers if data was text or binary - thus it can decrypt to/from text data. This was a major nuisance for encrypt(). * Stores info about used algorithms with result, so user needs not remember them - more user friendly! * Uses String2Key algorithms (similar to crypt()) with random salt to generate full-length binary key to be used for encrypting. * Uses standard format for data - you can feed it to GnuPG, if needed. Optional features (off by default): * Can use separate session key - user data will be encrypted with totally random key, which will be encrypted with S2K generated key and attached to result. * Data compression with zlib. * Can convert between CRLF<->LF line-endings - to get fully RFC2440-compliant behaviour. This is off by default as pgcrypto does not know the line-endings of user data. Interface is simple: pgp_encrypt(data text, key text) returns bytea pgp_decrypt(data text, key text) returns text pgp_encrypt_bytea(data bytea, key text) returns bytea pgp_decrypt_bytea(data bytea, key text) returns bytea To change parameters (cipher, compression, mdc): pgp_encrypt(data text, key text, parms text) returns bytea pgp_decrypt(data text, key text, parms text) returns text pgp_encrypt_bytea(data bytea, key text, parms text) returns bytea pgp_decrypt_bytea(data bytea, key text, parms text) returns bytea Parameter names I lifted from gpg: pgp_encrypt('message', 'key', 'compress-algo=1,cipher-algo=aes256') For text data, pgp_encrypt simply encrypts the PostgreSQL internal data. This maps to RFC2440 data type 't' - 'extenally specified encoding'. But this may cause problems if data is dumped and reloaded into database which as different internal encoding. My next goal is to implement data type 'u' - which means data is in UTF-8 encoding by converting internal encoding to UTF-8 and back. And there wont be any compatibility problems with current code, I think its ok to submit this without UTF-8 encoding by converting internal encoding to UTF-8 and back. And there wont be any compatibility problems with current code, I think its ok to submit this without UTF-8 support. Here is v4 of PGP encrypt. This depends on previously sent Fortuna-patch, as it uses the px_add_entropy function. - New function: pgp_key_id() for finding key id's. - Add SHA1 of user data and key into RNG pools. We need to get randomness from somewhere, and it is in user best interests to contribute. - Regenerate pgp-armor test for SQL_ASCII database. - Cleanup the key handling so that the pubkey support is less hackish. Marko Kreen
-