Hi,
I'm looking for a way to hidethe souce code
of mysystem (functions).
In Oracle, I can wrap it. Is there something
that I can use to hide and/orwrap my source code?
Att.Márcio A. SeppZYON TECNOLOGIA
LTDA
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?
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.
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
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...
--
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 forgot to 'cvs
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
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 there
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
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...
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:
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 buildfarm machines:
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 build I
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
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 buildfarm,
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.
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
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
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 perl
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 are
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 to
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 not
Bruce Momjian pgman@candle.pha.pa.us 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
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
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 (which
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
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
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
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
29 matches
Mail list logo
