On 7/19/05 8:11 AM, "Titus von Boxberg" <[EMAIL PROTECTED]> wrote:
>> As for NFIELDS, I don't think we need it -- you can always measure the
>> length of the FIELDNAMES array.
> I would like to leave it there. As far as I can see it's much faster
> than other builtins for evaluating array dimension
"Titus von Boxberg" <[EMAIL PROTECTED]> writes:
> Questions:
> - could anyone who knows Oracle better than me confirm
> that with Oracle there are no RECORD variables of varying
> dynamically assigned type?
Anyone?
> - is the syntax RECORD.(identifier), RECORD.(*), RECORD.(#)
> still accept
Hi,
I grabbed the patches to try, but I was wondering if it would be more
interesting to try them against CVS rather than 8.0.3 (and if it would
be easy to port :)?
Mark
---(end of broadcast)---
TIP 4: Have you searched our list archives?
I have looked more closely at what is happening during the link of the
contrib modules, and I agree that my original patch is too broad.
I am seeing that cube fails, but userlocks works. I have noticed that
cube is using a MODULE_big directive (which is failing to pick up all
libraries), but that
The problem trying to be fixed there seems to be related to libraries
being linked into the backend vs. frontend.
Since the contrib shared library modules are linked in a similar
environment backend code I decided to use BE_DLLLIBS.
Here is the new patch (which doesn't affect libpq).
-ro
Thanks, fix attached and applied
---
Eugen Nedelcu wrote:
> In function format_numericsep() you have:
>
> new_str = pg_local_malloc(len_numericseps(my_str) + 1),
>
> instead of:
>
> new_str = pg_local_malloc(len_with_nume
> -Ursprüngliche Nachricht-
> Von: Tom Lane
> An: Neil Conway
> Cc: Titus von Boxberg
> Betreff: Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
>
---
> There's a worse objection, which is that % is a perfectly valid operator
OK. I did not recognize that.
> Another sm
Kris Jurka <[EMAIL PROTECTED]> writes:
> The attached patch fixes this buildfarm failure:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canary&dt=2005-07-18%2015:30:01
Applied, thanks.
regards, tom lane
---(end of broadcast)--
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > OK, I have applied the following patch to make numerisep a boolean,
> >
> > "numericsep" is no longer even remotely reasonable as a name for the
> > parameter. Something like "numeric_use_locale" would be appropriate
> > (but
Marko Kreen writes:
> - reformat in asciidoc syntax
> - clarify various parts
> - add high-level description of PGP structure
> - add a comparison of crypt vs. regular hashes
Applied.
regards, tom lane
---(end of broadcast)
Marko Kreen writes:
> After studying Fortuna more, I found out that I missed
> some of the details.
> - reseeding should happen only if pool #0 has aquired additional
> entropy.
> - a 'rekeying' operation should happend after each request and
> also after 1M of extracted data. That means ta
Marko Kreen writes:
> - Fix couple comments.
> - internal.c didnt clean hash contexts when freeing
> - zero the system randomness buffer too
> - Google tells that we can use /dev/urandom on Cygwin,
> HPUX and AIX. Add them to random.c
> - remove a debug reference from pgp.h
Applied.
On Mon, Jul 18, 2005 at 12:32:21PM -0400, Tom Lane wrote:
> "Rocco Altier" <[EMAIL PROTECTED]> writes:
> > There are C++ style comments in contrib/pgcrypto which is giving cc
> > problems.
>
> Definitely contrary to project policy, will fix.
Don't, they are fixed in "small cleanups" patch that I
Marko Kreen writes:
> On Mon, Jul 18, 2005 at 12:32:21PM -0400, Tom Lane wrote:
>> Definitely contrary to project policy, will fix.
> Don't, they are fixed in "small cleanups" patch that I sent.
Too late, already committed ;-)
I will do something to clean up the mess...
The attached patch fixes this buildfarm failure:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canary&dt=2005-07-18%2015:30:01
Kris Jurka
Index: src/bin/pg_dump/po/pt_BR.po
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/
It looks like I jumped the gun a bit on sending out the patches, since I
was intending to have the failed build report show up in the buildfarm
at the same time.
I am running another build with send so that the error will show on the
build farm.
The animal name is appropiately: kookaburra
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Er, which buildfarm report is prompting this?
> Rocco is probably doing what I normally ask, which is to get builds
> working before starting to upload results to the buildfarm server (a
> request which is more honored in the breach
Tom Lane wrote:
"Rocco Altier" <[EMAIL PROTECTED]> writes:
Need to have these patches applied to get AIX 5.2 to build as a member
of the buildfarm.
Er, which buildfarm report is prompting this?
Rocco is probably doing what I normally ask, which is to get builds
working before
"Rocco Altier" <[EMAIL PROTECTED]> writes:
> Need to have these patches applied to get AIX 5.2 to build as a member
> of the buildfarm.
Er, which buildfarm report is prompting this?
> There are C++ style comments in contrib/pgcrypto which is giving cc
> problems.
Definitely contrary to project p
Need to have these patches applied to get AIX 5.2 to build as a member
of the buildfarm.
The Makefile.shlib patch allows all the contrib modules to build (this
seems to be the same problem that cygwin is facing). AIX needs -lm (to
pick up math routines for atleast cube module). I am not sure why
On Mon, 2005-06-27 at 01:41 +0100, Simon Riggs wrote:
> I enclose a fully working implementation of Constraint Exclusion, a very
> basic form of Partitioning. Initial review is requested, to allow us all
> to assess what further work is required on this prior to Beta freeze.
>
> Patch against curr
On Sat, 2005-07-02 at 18:29 -0400, Alvaro Herrera wrote:
> On Sat, Jul 02, 2005 at 03:56:48PM -0400, Bruce Momjian wrote:
>
> > Simon Riggs wrote:
> > >
> > > I enclose a fully working implementation of Constraint Exclusion, a very
> > > basic form of Partitioning. Initial review is requested, to
In function format_numericsep() you have:
new_str = pg_local_malloc(len_numericseps(my_str) + 1),
instead of:
new_str = pg_local_malloc(len_with_numericsep(my_str) + 1)
Another bug is in function len_numericseps(). This apear for querys
like:
select NULL::numeric; or
select * from table_with_
23 matches
Mail list logo
