Tom Lane writes:
> [cvs is your friend...] It appears to have been added as part of the
> MinGW porting work last May. I don't have much faith in it; as far as
> I heard the MinGW port never got further than making the client-side
> code work, and so this file has no real-world testing.
FWIW,
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I'm not sure there's any need for
>> src/backend/port/win32/sema.c at all.
> (Do you have any idea on the historical
> context of this code? I wondered as to, if we have no win32 port, why there
> would be a seemingly good-to-go sema
Tom Lane writes:
> > Just working with what we've already got. There seems to be very
> > usable code in src/backend/port/win32/sema.c, which gets invoked
> > as Win32 does not have spin-locks, but unfortunately relies on
> > ShmemInitStruct.
>
> Win32 certainly has spinlocks; it does not run
Claudio Natoli <[EMAIL PROTECTED]> writes:
>> The correct solution to that seems to lie elsewhere, ie, not use
>> semaphores for spinlocks.
> Just working with what we've already got. There seems to be very usable code
> in src/backend/port/win32/sema.c, which gets invoked as Win32 does not have
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Hannu Krosing wrote:
> > Eric Ridge kirjutas R, 09.01.2004 kell 01:16:
> >
> > > Forgetting about composite indexes for a moment, is postgres even
> > > capable of doing 2 index scans in this situation? Does it know how do
> > > take the intersection
> You have broken stuff before by rearranging the sequence of
operations...
Ah, yeah, well, FWIW, if that is the only thing that gets broken in the
process of making this port, I'll be more than satisfied. Will that be held
against me forever?
> what exactly have you got in mind here?
Moving
Hannu Krosing wrote:
> Eric Ridge kirjutas R, 09.01.2004 kell 01:16:
>
> > Forgetting about composite indexes for a moment, is postgres even
> > capable of doing 2 index scans in this situation? Does it know how do
> > take the intersection of two scans?
>
> Not currently, but it has been in T
ow <[EMAIL PROTECTED]> writes:
> Is this all that's planned for 7.5? (based on current TODO list)
If you think the TODO list has *anything* to do with release planning,
you fundamentally misunderstand the way things are done around here.
The TODO list is a list of things that are widely agreed to
[EMAIL PROTECTED] (Martin Marques) writes:
> Mensaje citado por "Marc G. Fournier" <[EMAIL PROTECTED]>:
>> Native Win32 is planned for it (whether it makes it or not is another
>> question, but it is the goal) ...
>
> Replication wasn't another BIG one?
Well, there are two "replication things" goi
On Mon, 12 Jan 2004, Martin Marques wrote:
> Mensaje citado por ow <[EMAIL PROTECTED]>:
>
> > Hi,
> >
> > Is this all that's planned for 7.5? (based on current TODO list)
> >
> > -Change factorial to return a numeric (Gavin)
> > -COMMENT ON [ CAST | CONVERSION | OPERATOR CLASS | LARGE OBJECT | LAN
On Mon, 12 Jan 2004, Martin Marques wrote:
> Mensaje citado por "Marc G. Fournier" <[EMAIL PROTECTED]>:
>
> >
> > Native Win32 is planned for it (whether it makes it or not is another
> > question, but it is the goal) ...
>
> Replication wasn't another BIG one?
Actually, I think it was PITR (P
Mensaje citado por ow <[EMAIL PROTECTED]>:
> Hi,
>
> Is this all that's planned for 7.5? (based on current TODO list)
>
> -Change factorial to return a numeric (Gavin)
> -COMMENT ON [ CAST | CONVERSION | OPERATOR CLASS | LARGE OBJECT | LANGUAGE ]
> (Christopher)
> -Have psql \dn show only visibl
Mensaje citado por "Marc G. Fournier" <[EMAIL PROTECTED]>:
>
> Native Win32 is planned for it (whether it makes it or not is another
> question, but it is the goal) ...
Replication wasn't another BIG one?
--
select 'mmarques' || '@' || 'unl.edu.ar' AS email;
---
Native Win32 is planned for it (whether it makes it or not is another
question, but it is the goal) ...
On Mon, 12 Jan 2004, ow wrote:
> Hi,
>
> Is this all that's planned for 7.5? (based on current TODO list)
>
> -Change factorial to return a numeric (Gavin)
> -COMMENT ON [ CAST | CONVERSION
Hi,
Is this all that's planned for 7.5? (based on current TODO list)
-Change factorial to return a numeric (Gavin)
-COMMENT ON [ CAST | CONVERSION | OPERATOR CLASS | LARGE OBJECT | LANGUAGE ]
(Christopher)
-Have psql \dn show only visible temp schemas using current_schemas()
-Have psql '\i ~/' ac
Sai Hertz And Control Systems wrote:
Dear Jan Wieck ,
Yes I agree with you Jan , most of the time we round the amount and
this is done by truncating greater than 3 decimal digits and
rounding the 3 digit to 2 in other words :
select trunc(1000.236897,3);
then
selecr round(1000.236,2);
This
Hannu Krosing wrote:
> IIRC, the charset transformations are done as a separate step in the
> wire protocol _before_ any parser has chance transform or not.
Yep. My point is that this is wrong. I think of XML the same way I
think of a zip file contains a text document. Postgres does not unzip a
Dear Jan Wieck ,
Yes I agree with you Jan , most of the time we round the amount and
this is done by truncating greater than 3 decimal digits and
rounding the 3 digit to 2 in other words :
select trunc(1000.236897,3);
then
selecr round(1000.236,2);
This takes care of the rounding factor in m
Tom Lane wrote:
> But this interacts with point 3 (psql breaks on every new backend
> version). It's not desirable to have every GUI and large custom
> program implementing its own set of metadata inquiry commands: they
> all have to go through the same update pain as psql. Perhaps if
> people st
Sai Hertz And Control Systems wrote:
Dear Jan Wieck ,
Floating point math itself is not precise, but rather an approximation,
usually of 8 or 14 digits. You can't approximate money. This isn't a
PostgreSQL issue but rather a general programming issue.
Thanks, Bruce. I assume the arbitrary pre
Dear Jan Wieck ,
Floating point math itself is not precise, but rather an approximation,
usually of 8 or 14 digits. You can't approximate money. This isn't a
PostgreSQL issue but rather a general programming issue.
Thanks, Bruce. I assume the arbitrary precision arithmetic Jan
mentioned which
Michael Glaesemann wrote:
On Jan 4, 2004, at 6:51 PM, Bruce Momjian wrote:
Michael Glaesemann wrote:
On Dec 29, 2003, at 11:28 AM, Sai Hertz And Control Systems wrote:
I would like to share my concerns about the IEEE 754 specification
and
floating point handling by PostgreSQL .
What specifically
Short story:
I need two new functions in the Server Programming Interface (SPI) when
mapping an ExecutionPlan to a Java prepared statement (pljava project).
Long story:
My problem is that once a plan is prepared and I want to execute it, I send
an array of java objects for the arguments. The SPI_c
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Are these comments still true? Specifically, is it necessary to call
> CreateLWLocks before InitShmemIndex? I think it used to be, but then the
> ShmemIndexLock got made into a separate spinlock in its own right.
I think the only dependency was that Shm
Chris,
do you have any additional info (email?) on how to contact the original
project admin? Is it possible for you to manually set up Shachar as admin on
the project?
Robert Treat
On Monday 12 January 2004 04:30, Shachar Shemesh wrote:
> Robert Treat wrote:
> >Can you fill us in on your e
Robert Treat wrote:
Can you fill us in on your efforts to contact the original project author?
Sure thing. Here it is:
The project is located at
http://gborg.postgresql.org/project/oledb/projdisplay.php. It has
released no code, shows no CVS activity, and seems rather empty. There
are two task
In CreateSharedMemoryAndSemaphores, there is the following comment, just
before CreateLWLocks():
/*
* Now initialize LWLocks, which do shared memory allocation and are
* needed for InitShmemIndex.
*/
Also, in InitShmemAllocation, there is:
/* ShmemInde
> -Original Message-
> From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
> Sent: 11 January 2004 20:21
> To: William ZHANG
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] OLE DB driver
>
> >AFAIK, rely on libpq is a fast way but not always convenient.
> >
> >
> Seems like more convine
28 matches
Mail list logo