> I see no concurrency problems. If two or more backends visit the same
> tuple, they either write the same value to the same position which
> doesn't hurt, or one sees the other's changes which is a good thing.
AFAIR, on multi-CPU platforms it's possible that second transaction could
see COMMITT
How can it recurse, actually - there won't be an index with the same name
in the subtable?
On Fri, 21 Mar 2003, Alvaro Herrera wrote:
> On Fri, Mar 21, 2003 at 11:21:16AM +0800, Christopher Kings-Lynne wrote:
> > Does the new ALTER TABLE / CLUSTER ON syntax support the ONLY modifier - it
> > isn'
We are working on that feature in 7.4. I have the patch at:
ftp://candle.pha.pa.us/pub/postgresql/mypatches
but it is only for 7.2.
---
Russ Mercer wrote:
> How can I compile the UltraSQL version of PostgreSQL for
How can I compile the UltraSQL version of PostgreSQL for Win32? I am looking for a
Win32 version of PostgreSQL that does not depend on cygwin, and UltraSQL seems to work
well.
This site (http://techdocs.postgresql.org/guides/Windows) only points to the UltraSQL
binaries (ftp://209.61.187.152/po
I have modified the patch to call it PQfreemem(), in case there are other
cases we need to free libpq memory.
Patch attached and applied.
---
Zeugswetter Andreas SB SD wrote:
>
> > Actually this isn't even working for me.
Patch backed out.
---
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > I've been getting regression test failures (int8 and numeric) for the
> > past couple of days. Looks like it is related to the recent to_cha
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > I've been getting regression test failures (int8 and numeric) for the
> > past couple of days. Looks like it is related to the recent to_char changes.
>
> Yeah, Bruce applied a to_char change that really wasn't ready, because
> (a) it d
PostgreSQL 7.3.2
CREATE DOMAIN testdom AS int4;
CREATE TABLE testtab(testcol testdom);
INSERT INTO testtab VALUES (1);
INSERT INTO testtab VALUES (2);
VACUUM ANALYZE testtab;
SELECT * FROM testtab WHERE testcol > 1;
The select will give
"ERROR: convert_numeric_to_scalar: unsupported type 33814
Joe Conway <[EMAIL PROTECTED]> writes:
> I've been getting regression test failures (int8 and numeric) for the
> past couple of days. Looks like it is related to the recent to_char changes.
Yeah, Bruce applied a to_char change that really wasn't ready, because
(a) it didn't include the necessary
I've been getting regression test failures (int8 and numeric) for the
past couple of days. Looks like it is related to the recent to_char changes.
Joe
*** ./expected/int8.out Fri Sep 20 09:44:55 2002
--- ./results/int8.out Fri Mar 21 14:57:18 2003
***
*** 160,166
|
Greg Stark <[EMAIL PROTECTED]> writes:
Neil Conway <[EMAIL PROTECTED]> writes:
> Note that it won't be a noise word: if NO SCROLL is specified, an
> attempt to do a backward fetch on a non-scrollable cursor will yield an
> error.
> Does the spec *require* an error, or merely say that backward fetc
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Fri, 2003-03-21 at 12:12, Tom Lane wrote:
> >> (No problem here with adding the noise-word option, of course.)
>
> > Note that it won't be a noise word: if NO SCROLL is specified, an
> > attempt to do a backwar
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2003-03-21 at 12:12, Tom Lane wrote:
>> (No problem here with adding the noise-word option, of course.)
> Note that it won't be a noise word: if NO SCROLL is specified, an
> attempt to do a backward fetch on a non-scrollable cursor will yield an
>
On Fri, 2003-03-21 at 12:12, Tom Lane wrote:
> Hm? As of CVS tip, SCROLL most definitely does something.
Sorry -- I noticed that it doesn't actually effect whether you can do
backward fetches on the cursor, which is what I should have said.
> (No problem here with adding the noise-word option, o
Neil Conway <[EMAIL PROTECTED]> writes:
> The SQL spec specifies that you should be able to specify NO SCROLL to
> DECLARE CURSOR to disallow bidirectional fetching on the cursor. We
> currently support the SCROLL syntax, but it had no significant effect on
> the behavior of the cursor. This was pr
Tom Lane writes:
> > for d in $(psql -l --somthing); do vacuum $d; done
> If you have a real shell (and know how to use it), sure. Is such a
> solution acceptable to all those Windows users we're hoping to attract?
I don't know how Windows users typically manage their systems, but if they
use ba
Folks,
While doing some other cursor-related work, I noticed the following two
issues:
(1) Lack of NO SCROLL
The SQL spec specifies that you should be able to specify NO SCROLL to
DECLARE CURSOR to disallow bidirectional fetching on the cursor. We
currently support the SCROLL syntax, but it had
On Fri, Mar 21, 2003 at 11:21:16AM +0800, Christopher Kings-Lynne wrote:
> Does the new ALTER TABLE / CLUSTER ON syntax support the ONLY modifier - it
> isn't documented if it is?? I guess it's not really relevant is it?
Oh, sorry, the command does not recurse. Should it? The whole CLUSTER
thin
On Fri, Mar 21, 2003 at 11:54:24AM +0800, Christopher Kings-Lynne wrote:
> I just managed to break the CLUSTER ON patch:
Damn... I dunno how I managed to miss this. Please apply the attached
patch.
--
Alvaro Herrera ()
Licensee shall have no right to use the Licensed Software
for productive or
>
> Hmm, maybe the transformation in the other direction is the culprit.
> What I do is call ts1 = PGTYPEStimestamp_atot("2000-7-12 17:34:29",
NULL); followed by a text = PGTYPEStimestamp_ttoa
(ts1); Needless to say the resulting text is not "2000-7-12 17:34:29".
:-(
>
I could not dig too deep into
>
> I started working on date/timestamp in ecpg. So far I can read date
> types from the DB and I can insert date into the DB. However there
seems
> to be a bug in converting timestamp to ascii or vice versa.
>
> If anyone of you knows more about timestamp2tm etc. could you please
> have a look at
21 matches
Mail list logo
