Hi,
I noticed we don't have ALTER TYPE foo RENAME TO bar command which would
be handy for me especially for enum types.
So I wrote this little patch (including very brief doc) which adds above
syntax. It basically just does some checks and calls existing TypeRename
function which is used for re
Hi,
attached patch adds chklocale.c to pgportfiles in Mkvcbuild perl module
(not really worth the .diff :))
This fixes MSVC build (see buildfarm errors with unresolved reference
for _pg_get_encoding_from_locale).
--
Regards
Petr Jelinek (PJMODOS)
Index: Mkvcbuild.pm
==
On 9/29/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Has anyone every asked for this functionality?
I searched the list archives for previous mentions of the topic, and
didn't find any. So the answer to your question is "yes", but so far
it seems to be just me.
Cheers,
BJ
On Fri, 2007-09-28 at 10:02 +0100, Heikki Linnakangas wrote:
> Well, yes it could, but why? Keeping them separate looks slightly more
> readable to me, and the change could break a lot of external modules for
> no good reason.
I agree: it also complicates the common case (calling relation_open()
a
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> solaris openssl refuses to handle keys longer than 128bits.
> ...
> So something like the current patch should be still applied
> as a near-term fix.
Applied to HEAD and 8.2. I wasn't sure if there was interest in
patching further back, or if the patch
Dave Page <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Is there any reason not to just do this on *all* platforms, and get rid
>> of all the #ifdefs?
> Yes, (see the comment in the code). We stat the private key on *nix to
> ensure it hasn't changed underneath us which can't be done usi
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Raney wrote:
> Hello All,
>
> We have prepared a patch (against CVS HEAD)for the TODO item:
> * Hash
>-Durin
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Marshall, Steve wrote:
>> This is probably not a big problem, since TCL was not commonly compiled
>> with multithreading enabled prior to 8.4. However, perhaps there should
>> be a warning in the documentation on PL/TCL directing users to avoid
>> linkin
Marshall, Steve wrote:
> >The recent TCL patch assumed Tcl_NotifierProcs.initNotifierProc
> >was added in TCL 8.2:
> >In fact it was added in 8.4 so I have modified the CVS with
> >the following patch.
>
> I confirmed this against the 8.2.5 release. Sorry I did not notice that
> when I initiall
Matt Newell wrote:
> On Friday 28 September 2007 14:04, Bruce Momjian wrote:
> > ** 178,184
> >* within Postgres, but we implement all the functions for completeness.
> >* We can only fix this with Tcl >= 8.2, when Tcl_SetNotifier() appeared.
> >*/
> > ! #if HAVE_TCL_VERSION(8,2)
>
Tom Lane wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Patch includes documentation and new regression tests. While I was in
> > there I also added regression tests for quote_ident(), which appeared
> > to be absent.
>
> This seems rather pointless, since it's equivalent to
> quot
On Friday 28 September 2007 14:04, Bruce Momjian wrote:
> ** 178,184
>* within Postgres, but we implement all the functions for completeness.
>* We can only fix this with Tcl >= 8.2, when Tcl_SetNotifier() appeared.
>*/
> ! #if HAVE_TCL_VERSION(8,2)
You missed the 8.2 in the comme
>The recent TCL patch assumed Tcl_NotifierProcs.initNotifierProc
>was added in TCL 8.2:
>In fact it was added in 8.4 so I have modified the CVS with
>the following patch.
I confirmed this against the 8.2.5 release. Sorry I did not notice that
when I initially created the patch.
While the patch
Dave Page wrote:
> Magnus Hagander wrote:
>> Hrrm. Obviously, I need to go sleep now. Sorry about that.
>>
>> But it'd be nice to get rid of all those #ifdef blocks..
>
> See the attached revision. This is untested as I don't have a linux box
> to hand, but I believe it's right.
Ignore that - I m
Magnus Hagander wrote:
> Hrrm. Obviously, I need to go sleep now. Sorry about that.
>
> But it'd be nice to get rid of all those #ifdef blocks..
See the attached revision. This is untested as I don't have a linux box
to hand, but I believe it's right.
/D
Index: src/interfaces/libpq/fe-secure.c
Dave Page wrote:
> Magnus Hagander wrote:
>> Dave Page wrote:
>>> Dave Page wrote:
Dave Page wrote:
> I did stumble across this text on a mailing list in response to someone
> with a similar problem in some JNI code. I know little of the OpenSSL
> API, but perhaps it rings bells wi
The recent TCL patch assumed Tcl_NotifierProcs.initNotifierProc was
added in TCL 8.2:
#if HAVE_TCL_VERSION(8,2)
/*
* Override the functions in the Notifier subsystem. See comments
above.
*/
{
Tcl_NotifierProcs notifier;
Magnus Hagander wrote:
> Dave Page wrote:
>> Dave Page wrote:
>>> Dave Page wrote:
I did stumble across this text on a mailing list in response to someone
with a similar problem in some JNI code. I know little of the OpenSSL
API, but perhaps it rings bells with you before I spend my
Dave Page wrote:
> Dave Page wrote:
>> Dave Page wrote:
>>> I did stumble across this text on a mailing list in response to someone
>>> with a similar problem in some JNI code. I know little of the OpenSSL
>>> API, but perhaps it rings bells with you before I spend my evening
>>> trying to figure i
Hi,
Starting from version VC7 msvc supports __FUNCTION__, so I think this
could be enabled in pg_config.h.win32, see attached diff.
-Hannes
*** ../pgsql-cvshead/src/include/pg_config.h.win32 Mon Apr 16 20:39:19 2007
--- src/include/pg_config.h.win32 Fri Sep 28 22:32:50 2007
***
Dave Page wrote:
> Dave Page wrote:
>> I did stumble across this text on a mailing list in response to someone
>> with a similar problem in some JNI code. I know little of the OpenSSL
>> API, but perhaps it rings bells with you before I spend my evening
>> trying to figure it out?
>
> OK, I think
Dave Page wrote:
> I did stumble across this text on a mailing list in response to someone
> with a similar problem in some JNI code. I know little of the OpenSSL
> API, but perhaps it rings bells with you before I spend my evening
> trying to figure it out?
OK, I think I've figured out a fix. Wor
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Doesn't really matter. Even if we were willing to hack our own client
apps like that (which I'm not), we can *not* transfer such a requirement
onto every libpq-using application. It's just not acceptable.
*We're* not tran
Dave Page <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Doesn't really matter. Even if we were willing to hack our own client
>> apps like that (which I'm not), we can *not* transfer such a requirement
>> onto every libpq-using application. It's just not acceptable.
> *We're* not transfering
Dave Page wrote:
Is it possible to use GNUTLS on Windows?
No, I don't think so. I didn't think we accepted Martijn's(?) patch
for it anyway?
This mess might make that worth revisiting, if it can be used on
Windows. See http://josefsson.org/gnutls4win/
cheers
andrew
--
Marko Kreen wrote:
On 9/28/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Dave Page <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to l
On 9/28/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
> > Andrew Dunstan wrote:
> >> Then I think I'd rather disable use of client certs for the offending
> >> openssl versions in libpq, or let the apps die and refer the customers
> >> to the openssl people to lobb
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to lobby them for a sane solution.
If this were 8.0 I
Dave Page <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Then I think I'd rather disable use of client certs for the offending
>> openssl versions in libpq, or let the apps die and refer the customers
>> to the openssl people to lobby them for a sane solution.
> If this were 8.0 I'd agre
Heikki Linnakangas wrote:
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
whic
Dave Page wrote:
> Andrew Dunstan wrote:
>> Dave Page wrote:
>>> I believe we just didn't notice it until now because the older Mingw
>>> builds use the MSVC 6.0 runtimes which just happened to be compatible
>>> with the OpenSSL binary builds (we're now using 8.0), in addition to
>>> which there ar
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to lobby them for a sane solution.
If this were 8.0 I'd agree, but thats not a nice solution for those
alrea
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be
compatible with the OpenSSL binary builds (we're now using 8.0), in
addition to which there are relativ
Andrew Dunstan wrote:
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
which there are relatively few people using
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
which there are relatively few people using client-side certs I'd
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
The server doesn't seem to be affected, but the attached patch fixes the
problem for the client apps. Unfortunately it must be included in the
app itself, and not libpq.
This is pretty much in the category of "they've got to be kidding".
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
The server doesn't seem to be affected, but the attached patch fixes the
problem for the client apps. Unfortunately it must be included in the
app itself, and not libpq.
This is pretty much in the category of "they've got to be ki
solaris openssl refuses to handle keys longer than 128bits.
* aes will crash on longer keys
* blowfish will silently cut the key which can result
data corruption
to fix it:
- test errors from AES functions
- bf errors cannot be tested, do test encryption
- change aes compat macros to static fu
Dave Page <[EMAIL PROTECTED]> writes:
> The server doesn't seem to be affected, but the attached patch fixes the
> problem for the client apps. Unfortunately it must be included in the
> app itself, and not libpq.
This is pretty much in the category of "they've got to be kidding".
I recommend sitt
On Windows the OpenSSL guys have included code with 0.9.8 and above to
allow OpenSSL to work correctly regardless of the MSVC runtime libraries
that have been used with the host application. This has become noticable
with the MSVC++ build in which any client apps that connect using libpq
with a cli
Jaime Casanova wrote:
> I can understand why we have relation_openrv and try_relation_open,
> but relation_open_nowait can be merged with relation_open.
Well, yes it could, but why? Keeping them separate looks slightly more
readable to me, and the change could break a lot of external modules for
n
Hi,
I can understand why we have relation_openrv and try_relation_open,
but relation_open_nowait can be merged with relation_open.
Or there is something i'm missing? attached is a patch that do the merge.
--
regards,
Jaime Casanova
"Programming today is a race between software engineers strivi
42 matches
Mail list logo
