Neil Conway <[EMAIL PROTECTED]> writes:
> Fair enough -- although there's a major difference between the
> meta-data stored about tables (which are permanent database objects
> and are typically complex), and prepared statements (which (at
> present) are only stored for the duration of the current
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, can you clarify why -0 is valid.
The IEEE spec absolutely thinks that -0 and +0 are distinct entities.
I don't remember why, at one in the morning ... but if you insist I'm
sure that plenty sufficient numerical-analysis reasons can be produced.
The
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Why would this be needed? Couldn't we rely on the client programmer to
> > know that '$n is of type foo', and then pass the appropriately-typed
> > data to EXECUTE?
>
> I don't think so. You may as well ask why we
Tom, can you clarify why -0 is valid. Is it for _small_ near zero
values that are indeed negative?
---
Tom Lane wrote:
> Patrick Welche <[EMAIL PROTECTED]> writes:
> > On Tue, Nov 19, 2002 at 10:53:59AM -0500, Tom Lane wrot
Patrick Welche <[EMAIL PROTECTED]> writes:
> On Tue, Nov 19, 2002 at 10:53:59AM -0500, Tom Lane wrote:
>> Presumably that was put in because it was correct on i86. How do you
>> feel about changing that entry to
>> geometry/i.86-.*-netbsd=geometry-positive-zeros
>> rather than deleting it?
> I wa
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> This form of PREPARE would presumably need some way of reporting back
>> the types it had determined for the symbols; anyone have a feeling for
>> the appropriate API for that?
> Why would this be needed? Couldn't we
Tom Lane <[EMAIL PROTECTED]> writes:
> Thinking about this, it occurs to me that there's no good reason why
> we couldn't allow parameter symbols ($n) to be considered type UNKNOWN
> initially.
Good idea.
> This form of PREPARE would presumably need some way of reporting back
> the types it had d
Backed out. Peter. thanks for spotting that.
Patrick, would you please test 7.3RC1?
---
Peter Eisentraut wrote:
> He was testing 7.4devel. That's not the right one.
>
> Bruce Momjian writes:
>
> >
> > Ports list updated:
He was testing 7.4devel. That's not the right one.
Bruce Momjian writes:
>
> Ports list updated:
>
> http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html
>
> ---
> Patrick Welche wrote:
> > On Thu, Nov
On Tue, Nov 19, 2002 at 10:53:59AM -0500, Tom Lane wrote:
> Patrick Welche <[EMAIL PROTECTED]> writes:
> > [remove this:]
> > -geometry/.*-netbsd=geometry-positive-zeros
>
> > as this acorn32 is running on a StrongARM processor, so has nothing to do
> > with libm387. Maybe get rid of the geometry-
On Tue, 19 Nov 2002, Josh Berkus wrote:
> Folks,
>
> We need a quote from a major code contributor to PostgreSQL about the
> upcoming 7.3 release -- something about how great the new release is,
> or some of the features in the release. We need this for the 7.3
> press release, which will be d
Folks,
We need a quote from a major code contributor to PostgreSQL about the
upcoming 7.3 release -- something about how great the new release is,
or some of the features in the release. We need this for the 7.3
press release, which will be drafted in 2 days.
If you have something to say, pleas
Ports list updated:
http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html
---
Patrick Welche wrote:
> On Thu, Nov 14, 2002 at 09:06:01AM -0500, Tom Lane wrote:
> > "Magnus Naeslund(f)" <[EMAIL PROTECTED
Patrick Welche <[EMAIL PROTECTED]> writes:
> [remove this:]
> -geometry/.*-netbsd=geometry-positive-zeros
> as this acorn32 is running on a StrongARM processor, so has nothing to do
> with libm387. Maybe get rid of the geometry-positive-zeros and see if
> someone complains and tells me otherwise?
On Thu, Nov 14, 2002 at 09:06:01AM -0500, Tom Lane wrote:
> "Magnus Naeslund(f)" <[EMAIL PROTECTED]> writes:
> > OK OK, before anyone rubs my nose in it, i see the fork() failures :)
>
> > I'll see what's causing the fork() problems...
>
> Too low processes-per-user limit, likely.
Success for
P
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> I think it is not really a weakness of the scheme, but a weakness that typmod
> is not available in some places where it would actually be needed.
> One effect of this is, that all the varlena datatypes have a redundant
> length info per r
To whom it may concern,
I am a java developer using postgres as a DB server. Me and my development team have a product comprised of about 50 tables, with about 10,000 records in the largest table. We have looked for concrete answers in books and the web for solutions to several problems that are
> >> Hmm ... now that's an interesting thought. So the input converter would
> >> actively strip trailing blanks, output would add them back,
>
> > But how would the output know how many to put back?
>
> The output routine would need access to the column typmod. Which it
> would have, in simpl
18 matches
Mail list logo
