Thomas Hallgren wrote:
Kris Jurka wrote:
3) By value: pljava does not correctly handle passed by value types
correctly, allowing access to random memory.
This is simply not true. There's no way a Java developer can access
random memory through PL/Java.
No, the point is that the Java devel
Robert Haas writes:
> I'm interested to know whether anyone else shares my belief that
> nested loops are the cause of most really bad plans. What usually
> happens to me is that the planner develops some unwarranted optimism
> about the number of rows likely to be generated by the outer side of
Kris Jurka wrote:
3) By value: pljava does not correctly handle passed by value types
correctly, allowing access to random memory.
This is simply not true. There's no way a Java developer can access
random memory through PL/Java.
- thomas
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Sat, 2 Aug 2008, Tom Lane wrote:
So what exactly does happen when the user deliberately specifies wrong
typlen/typbyval/typalign info when creating a type based on PL/Java
functions?
I have reviewed pljava's handling of misrepresented alignment, length, and
by value parameters
1) Align
> Actually, a simple algorithm that might work really well would be to
> calculate relation cache odds as ( number of page accesses for relation /
> number of page accesses for all relations ) * ( sum(relpages)*BLKSZ /
> eff_cache_size ), where number of page accesses would be both from relcache
>
On Feb 15, 2009, at 9:54 PM, Robert Haas wrote:
On Sun, Feb 15, 2009 at 1:16 PM, Greg Smith
wrote:
On Fri, 13 Feb 2009, Robert Haas wrote:
This seems plausible, but I'm not totally sold: predicting the
contents of the operating system buffer cache sounds like it might be
pretty touch. And do
Brendan Jurd writes:
> On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane wrote:
>> The point I'm trying to make is that we should deliver IEEE-compliant
>> results if we are on a platform that complies with the spec. Right down
>> to the minus sign. If that surprises people who are unfamiliar with the
Pavel Stehule wrote:
2009/2/17 Josh Berkus :
All,
I thought we'd agreed to compromise on having SE without row-level in 8.4,
and working on SE with row-level in 8.5. Why are we revisiting this
argument? 8.4 is *already* late; arguing further about the terms of SE
simply risk us being forced t
Hi,
I see a regression test failure in my mingw-vista port
when I invoke the command
make check MULTIBYTE=euc_jp NO_LOCALE=yes
.
It causes a crash at tsearch.
The crash seems to occur when the server encoding isn't
UTF-8 with no locale.
The attached is a patch to avoid the crash.
regards,
Hiros
Tom Lane wrote:
> Bruce Momjian writes:
> > I would like to add a --freeze parameter to vacuumdb for use by the
> > binary upgrade utility, and for symmetry with the existing VACUUM
> > options; patch attached.
>
> Exactly what do you think the upgrade utility is going to do with it?
> Surely no
Bruce Momjian writes:
> I would like to add a --freeze parameter to vacuumdb for use by the
> binary upgrade utility, and for symmetry with the existing VACUUM
> options; patch attached.
Exactly what do you think the upgrade utility is going to do with it?
Surely not a database-wide VACUUM FREEZ
I wrote:
> In the meantime I'm more convinced than ever that we should throw an
> error for attempting such a cast. If people are imagining that it will
> do something like that, we need to disillusion them.
BTW, I wrote up what I thought was a trivial patch to make this happen,
and promptly got
The attached patch adds to pg_dumpall --binary-upgrade by restoring
information about frozen xids for relations and databases. I think this
is the last patch I need to complete my TODO items for the pg_migrator
binary upgrade utility.
--
Bruce Momjian http://momjian.us
EnterpriseDB
2009/2/17 Josh Berkus :
> All,
>
> I thought we'd agreed to compromise on having SE without row-level in 8.4,
> and working on SE with row-level in 8.5. Why are we revisiting this
> argument? 8.4 is *already* late; arguing further about the terms of SE
> simply risk us being forced to reject it e
All,
I thought we'd agreed to compromise on having SE without row-level in
8.4, and working on SE with row-level in 8.5. Why are we revisiting
this argument? 8.4 is *already* late; arguing further about the terms
of SE simply risk us being forced to reject it entirely.
--Josh
--
Sent via
2009/2/17 Tom Lane :
> I wrote:
>> ITAGAKI Takahiro writes:
>>> I hope anyelement could be used in cast because casts are supported by
>>> almost programming languages where template or generics are available.
>
>> I think what you're suggesting is that inside a polymorphic function,
>> anyelement
David Fetter writes:
> On Tue, Feb 17, 2009 at 05:17:40PM +0100, Marco Colombo wrote:
>> Is it possibile to use some unicode character which is unlikely to
>> appear in the data set as delimiter? Something like U+FFFC.
> No. The delimiter needs to be one byte long at the moment. The error
> mes
Brendan Jurd writes:
> On Wed, Feb 18, 2009 at 2:40 AM, Tom Lane wrote:
>> After thinking about it for awhile, I don't like the notation anyway
>> --- it's not immediately obvious that a cast to anyelement should mean
>> something like that. What seems more sensible to me is to introduce
>> a fu
On Wed, Feb 18, 2009 at 2:40 AM, Tom Lane wrote:
> After thinking about it for awhile, I don't like the notation anyway
> --- it's not immediately obvious that a cast to anyelement should mean
> something like that. What seems more sensible to me is to introduce
> a function to get the type of an
On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane wrote:
> The point I'm trying to make is that we should deliver IEEE-compliant
> results if we are on a platform that complies with the spec. Right down
> to the minus sign. If that surprises people who are unfamiliar with the
> spec, well, there are a l
On Tue, Feb 17, 2009 at 05:17:40PM +0100, Marco Colombo wrote:
> Tom Lane wrote:
> > Andrew Gould writes:
> >> To the list: Does pg_dump escape characters that are the same as the
> >> delimiter?
> >
> > Yes. The OP has not actually explained why he needs to pick a
> > nondefault delimiter, unl
hi,
[I am working in the same team as Niranjan]
Niranjan wrote:
> > 3) Do you have test programs that can used
> > for synchronous replication testing?
>
> No, I've not used the automated test program. Yeah, since
> it's very useful, I'll make it before long.
>
> > 4) I'am thinking of trying
Peter Eisentraut wrote:
> Log Message:
> ---
> Redefine _() to dgettext() instead of gettext() so that it uses the plpgsql
> text domain, instead of the postgres one (or whatever the default may be).
Hmm, so is this needed on all other PLs too?
--
Sent via pgsql-hackers mailing list (pgs
I would like to add a --freeze parameter to vacuumdb for use by the
binary upgrade utility, and for symmetry with the existing VACUUM
options; patch attached.
I could also accomplish with with PGOPTIONs but this seem like a cleaner
solution.
--
Bruce Momjian http://momjian.us
Enter
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> plperl's nls.mk contains
>>
>> GETTEXT_TRIGGERS:= _ errmsg errdetail errdetail_log errhint errcontext
>> write_stderr croak Perl_croak
>>
>> As far as I can tell, croak() and Perl_croak() are provided by the Perl
>> library. So it is quite
Peter Eisentraut wrote:
> plperl's nls.mk contains
>
> GETTEXT_TRIGGERS:= _ errmsg errdetail errdetail_log errhint errcontext
> write_stderr croak Perl_croak
>
> As far as I can tell, croak() and Perl_croak() are provided by the Perl
> library. So it is quite unclear to me how we expect their
Gregory Stark writes:
> Tom Lane writes:
>> I'm of the opinion that minus zero was put into the IEEE floating point
>> standard by people who know a great deal more about the topic than
>> anyone on this list does, and that we do not have the expertise to be
>> second-guessing how it should work.
Applied.
---
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Tom Lane wrote:
> > >> Is this acceptable to everyone? We could name the option
> > >> -u/--upgrade-compatible.
> > >
> > > If the switch is specifically for
I wrote:
> ITAGAKI Takahiro writes:
>> I hope anyelement could be used in cast because casts are supported by
>> almost programming languages where template or generics are available.
> I think what you're suggesting is that inside a polymorphic function,
> anyelement would somehow be a macro for
Hi,
It's possible - I used unofficial BNF graph from internet.
so problem is on my side.
thank you
Pavel
2009/2/17 Peter Eisentraut :
> Pavel Stehule wrote:
>>
>> I found BNF for SQL 2003 and I found there some small difference.
>> Standard use keyword ESCAPE, but PostgreSQL use keybord UESCAP
Pavel Stehule wrote:
I found BNF for SQL 2003 and I found there some small difference.
Standard use keyword ESCAPE, but PostgreSQL use keybord UESCAPE.
Anybody knows reason?
::=
[ ]
U [ ... ]
[ { [ ... ] }... ]
[ ESCAPE ]
My copy has
::=
Tom Lane writes:
> The CVS commit message says
> Check for zero in unary minus floating point code (IEEE allows an
> explicit negative zero which looks ugly in a query result!).
> I'm of the opinion that minus zero was put into the IEEE floating point
> standard by people who know a
Tom Lane wrote:
> ITAGAKI Takahiro writes:
> > We already have some codes to avoid -0 float8um (unary minus),
> > but there are no protection in trunc(), ceil() and round() at least.
>
> I looked into the CVS history to find out when the anti-minus-zero code
> got put into float8um. It seems to
On Mon, Feb 16, 2009 at 08:03:33PM -0500, Tom Lane wrote:
> ITAGAKI Takahiro writes:
> > I hope anyelement could be used in cast because casts are supported by
> > almost programming languages where template or generics are available.
Programming languages with "generics" (aka, parametric polymor
plperl's nls.mk contains
GETTEXT_TRIGGERS:= _ errmsg errdetail errdetail_log errhint errcontext
write_stderr croak Perl_croak
As far as I can tell, croak() and Perl_croak() are provided by the Perl
library. So it is quite unclear to me how we expect their argument
strings to be translated u
35 matches
Mail list logo
