On 11/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > On 11/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Why? I can't imagine any real use for it. If you're thinking that
> >> it could provide a guide as to what to resize the buffer to, think
> >> aga
On 11/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > FWIW, SUS says that vsnprintf should act like snprintf and snprintf:
>
> I dunno where you're reading that, but it's certainly nowhere to be
> found in the version that I read:
>
> http://www.opengroup.
I have applied the attached patch to fix your ssize_t problem under
Borland CC. Plesae test. I am now looking at your linking issue.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is
In looking at the use of the thousands separator in formatting.c and
psql/print.c, I now see similar problems with the MONEY type, namely
that if the thousands separator is "" it is set to "," even if the
decimal separator is ",".
The attached patch fixes this.
I also removed a ssymbol test becau
Tom Lane <[EMAIL PROTECTED]> writes:
> Hannes Eder <[EMAIL PROTECTED]> writes:
> > in parse_expr.c:typecast_expression: return immediate on NULL
> input, i.e. do not lookup target type Oid as it is not required.
>
> I think the existing ordering is intentional, to detect and error
> out if the giv
On 11/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Attached patch moves decision how much more room to allocate
> > from callers of appendStringInfoVA to inside the function,
> > where more info is available.
>
> This is by no stretch of the imagination
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Attached patch moves decision how much more room to allocate
> from callers of appendStringInfoVA to inside the function,
> where more info is available.
This is by no stretch of the imagination "cleaner".
> On systems with broken vsnprintf() it falls b
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Actually, the meaning could be changed to *needmore
> and compensated inside function:
How's that different from the existing function result?
regards, tom lane
---(end of broadcast)--
Marko Kreen escribió:
> On 11/23/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > (If you are really interested in a fix for 7.3, let me know too ... I
> > couldn't even get plpython to run a trivial function due to RExec
> > issues. I didn't try 7.2).
>
> RExec seems to hint that 7.3 can work
in parse_expr.c:typecast_expression: return immediate on NULL input,
i.e. do not lookup target type Oid as it is not required.
-Hannes
Index: src/backend/parser/parse_expr.c
===
--- src/backend/parser/parse_expr.c (revision 377)
Attached patch moves decision how much more room to allocate
from callers of appendStringInfoVA to inside the function,
where more info is available.
On systems with broken vsnprintf() it falls back
to doubleing the buffer.
Fixme: the +1 could be something larger? Aligned?
--
marko
cleaner_a
Hannes Eder <[EMAIL PROTECTED]> writes:
> in parse_expr.c:typecast_expression: return immediate on NULL input,
> i.e. do not lookup target type Oid as it is not required.
I think the existing ordering is intentional, to detect and error out
if the given typename is bogus.
It's fairly likely that
Euler Taveira de Oliveira wrote:
> Bruce Momjian wrote:
>
> > OK, I researched this and realized it should have been obvious to me
> > when I added this code in 2006 that making the thousands separator
> > always "," for a locale of "" was going to cause a problem.
> >
> I tested your patch and I
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> FWIW, SUS says that vsnprintf should act like snprintf and snprintf:
I dunno where you're reading that, but it's certainly nowhere to be
found in the version that I read:
http://www.opengroup.org/onlinepubs/007908799/xsh/vfprintf.html
14 matches
Mail list logo
