I wrote:
> It occurs to me that a cleaner solution would be to stop giving domain
> types the same typinput routines as their base types. Instead, give
> them all a specialized routine domain_in (comparable to array_in) that
> first invokes the base type's input function and then applies any
> rel
Looking further ... we already do this implicitly for prodesc in the
call handler - we would just need to do the same thing for per-call
structures and divorce them from prodesc, which can be repeated on the
implicit stack.
I'll work on that - changes should be quite small.
Sounds like recur
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Works for me. There are some other things about the procdesc stuff
I'm trying to sort out (especially if we should be storing per-call
info inside it).
Hmm, probably not ... check to see if a recursive
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Works for me. There are some other things about the procdesc stuff I'm
trying to sort out (especially if we should be storing per-call info
inside it).
Hmm, probably not ... check to see if a recursive plperl function
behav
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> . I am seeing LOTS of warnings (not for plperl) about mismatched
> signedness of things
Yeah, the multibyte code is just full of places where "char *" is passed
to "unsigned char *" or vice versa. It's harmless, but on compilers
that warn about that (
I am not seeing it on FC4/perl5.8.6:
make[3]: Entering directory `/home/andrew/pg/pgsql/src/pl/plperl'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wold-style-definition -Wendif-labels
-fno-strict-aliasing -g -fpic -I. -I../../../src/include -D_GNU_SOURCE
Bruce Momjian writes:
> I am seeing this compile warning in plperl:
> plperl.c:1622: warning: passing arg 1 of `Perl_newSVpv' discards
> qualifiers from pointer target type
> Is anyone else seeing this? This is with:
> Summary of my perl5 (5.0 patchlevel 5 subversion 3) config
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Works for me. There are some other things about the procdesc stuff I'm
> trying to sort out (especially if we should be storing per-call info
> inside it).
Hmm, probably not ... check to see if a recursive plperl function
behaves sanely. (This might
On Sun, Jul 10, 2005 at 04:26:26AM -0300, M?rcio A. Sepp wrote:
> Hi,
>
> I'm looking for a way to hide the souce code of my system
> (functions).
>
> In Oracle, I can wrap it. Is there something that I can use to hide
> and/or wrap my source code?
If you have code that you don't want people
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have just noticed this code in plperl.c:
hv_store(plperl_proc_hash, internal_proname, proname_len,
newSViv((IV) prodesc), 0);
basically, here prodesc is a pointer to a struct, and we ar
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have just noticed this code in plperl.c:
> hv_store(plperl_proc_hash, internal_proname, proname_len,
> newSViv((IV) prodesc), 0);
> basically, here prodesc is a pointer to a struct, and we are storing it
> as an integer in a
I am seeing this compile warning in plperl:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing
-O1 -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith
-Wcast-align -fpic -I. -I../../../src/include
-I/usr/local/include/readline -I/u
I have just noticed this code in plperl.c:
hv_store(plperl_proc_hash, internal_proname, proname_len,
newSViv((IV) prodesc), 0);
basically, here prodesc is a pointer to a struct, and we are storing it
as an integer in a perl hash for easy lookup by stringified oid.
How
Whilst working on the change I proposed to make domain types enforce
their constraints inside the typinput/typreceive routines, I realized
that there's a fairly serious flaw in the design of typreceive routines:
we don't pass them a typmod so they cannot enforce type-specific typmod
restrictions.
Patch applied. Thanks.
---
Marko Kreen wrote:
> On Sun, Jul 10, 2005 at 09:10:29PM +0300, Marko Kreen wrote:
> > On Sun, Jul 10, 2005 at 11:37:22AM -0400, Bruce Momjian wrote:
> > > Marko Kreen wrote:
> > > > I see from bu
On Sun, Jul 10, 2005 at 09:10:29PM +0300, Marko Kreen wrote:
> On Sun, Jul 10, 2005 at 11:37:22AM -0400, Bruce Momjian wrote:
> > Marko Kreen wrote:
> > > I see from buildfarm, that pgcrypto fails to build on a
> > > non-OpenSSL machine. The reason for it is a stale openssl/bn.h
> > > include in p
On Sun, Jul 10, 2005 at 11:37:22AM -0400, Bruce Momjian wrote:
> Marko Kreen wrote:
> > I see from buildfarm, that pgcrypto fails to build on a
> > non-OpenSSL machine. The reason for it is a stale openssl/bn.h
> > include in pgp-pubdec.c. I did not spot it, as even for
> > --without-openssl buil
Marko Kreen wrote:
> On Sun, Jul 10, 2005 at 10:00:04AM -0400, Bruce Momjian wrote:
> > Marko Kreen wrote:
> > > On Sun, Jul 10, 2005 at 10:59:35AM +0200, Stefan Kaltenbrunner wrote:
> > > > looks like the latest pgcrypto-patches that just got applied cause
> > > > widespread failures on the buildf
On Sun, Jul 10, 2005 at 10:00:04AM -0400, Bruce Momjian wrote:
> Marko Kreen wrote:
> > On Sun, Jul 10, 2005 at 10:59:35AM +0200, Stefan Kaltenbrunner wrote:
> > > looks like the latest pgcrypto-patches that just got applied cause
> > > widespread failures on the buildfarm machines:
> > >
> > > ht
Add pg_dump --encoding.
Patch applied. Thanks.
---
Magnus Hagander wrote:
> > > I *think* that's easy enough to do in time for 8.1. Trivial patch
> > > attached. I hope it's enough :-) It passed my very quick testing...
Patch applied. Thanks.
---
Andrew Dunstan wrote:
>
> This patch implements putting language handlers for the optional PLs
> into pg_catalog rather than public, and supports dumping languages whose
> handlers are found t
On Sun, Jul 10, 2005 at 10:00:04AM -0400, Bruce Momjian wrote:
> All new files added, and I think all the pgcrypto patches are now
> applied to CVS. I just added the openssl version patch, I see the
> IMMUTABLE patch is already in, and I see the autoconfiguration stuff is
> already in.
>
> Is the
I will be in San Jose Monday through Wednesday, so I will not be reading
email as frequently. I am working my way through the patch queue.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard dri
Marko Kreen wrote:
> On Sun, Jul 10, 2005 at 10:59:35AM +0200, Stefan Kaltenbrunner wrote:
> > looks like the latest pgcrypto-patches that just got applied cause
> > widespread failures on the buildfarm machines:
> >
> > http://www.pgbuildfarm.org/cgi-bin/show_status.pl
>
> Seems like Bruce forgo
On Sun, Jul 10, 2005 at 10:59:35AM +0200, Stefan Kaltenbrunner wrote:
> looks like the latest pgcrypto-patches that just got applied cause
> widespread failures on the buildfarm machines:
>
> http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Seems like Bruce forgot to 'cvs add' new files...
--
m
looks like the latest pgcrypto-patches that just got applied cause
widespread failures on the buildfarm machines:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Stefan
---(end of broadcast)---
TIP 5: don't forget to increase your free space ma
Márcio A. Sepp wrote:
Hi,
I'm looking for a way to hide the souce code of my system (functions).
In Oracle, I can wrap it. Is there something that I can use to hide
and/or wrap my source code?
Att.
Márcio A. Sepp
ZYON TECNOLOGIA LTDA
Currently there is no way to do that.
On Sun, Jul 10, 2005 at 04:26:26AM -0300, Márcio A. Sepp wrote:
> I'm looking for a way to hide the souce code of my system (functions).
>
> In Oracle, I can wrap it. Is there something that I can use to hide
> and/or wrap my source code?
Write the functions in C and distribute only a binary?
Hi,
I'm looking for a way to hide the souce code
of my system (functions).
In Oracle, I can wrap it. Is there something
that I can use to hide and/or wrap my source code?
Att. Márcio A. SeppZYON TECNOLOGIA
LTDA
29 matches
Mail list logo
