Hello all,
And the answer is no, you can't. Recreate the table with correct types
and insert the old values into it.
You're kidding me, right? *prepares to gargle* MS Sql server can. Surely
we can implement this feature or aren't we aiming to go head to head with
commercial rdbms'?
The
Hello,
Are there built-in functions to convert UTF-8 string values into
hexadecimal \u and octal values and conversely?
If yes, can I parse any UTF-8 string safely with PL/pgSQL to return \u
and octal values?
Best regards,
Jean-Michel POURE
---(end of
On Mon, Sep 24, 2001 at 06:04:17PM +0100, Patrick Welche wrote:
...
and CVSROOT is not set as an environment variable... Also odd that it
appears there and there is no sign of home anywhere..
Got it: had /home/... in pgsql/src/backend/access/heap/CVS/Repository (!)
All OK now..
Cheers,
In a C application I want to run several
insert commands within a chained transaction
(for faster execution).
From time to time there will be an insert command
causing an
ERROR: Cannot insert a duplicate key into a unique index
As a result, the whole transaction is aborted and all
the
Hi,
* Tatsuo Ishii [EMAIL PROTECTED] [010925 18:18]:
So, this shows two problems :
- length() on the server side doesn't handle correctly Unicode [I
have the same result with char_length()], and returns the number
of chars (as it is however advertised to do), rather the length
Hello all,
And the answer is no, you can't. Recreate the table with correct types
and insert the old values into it.
You're kidding me, right? *prepares to gargle* MS Sql server can. Surely
we can implement this feature or aren't we aiming to go head to head with
commercial rdbms'?
The
- length() on the server side doesn't handle correctly Unicode [I
have the same result with char_length()], and returns the number
of chars (as it is however advertised to do), rather the length
of the string.
This is a known limitation.
To solve this, we could use
Marc G. Fournier writes:
with all the changes going on, we're most likely looking at Oct 1st,
earliest ... things are startin to stabilize, but until that 18gig is
installed next week, we still have th eproblems with updating ftp, unless
Peter can clear out th e400+Meg in his acount?
Jean-Michel POURE wrote:
Is this the way we should proceed with pgAdmin II?
Is anyone planning a real dependency table based on object STRING NAMES?
We need some advice:
1) Client solution: should we add the rebuilding feature to pgAdmin II?
2) Server solution: should we wait until the
The O_DIRECT flag has been added in FreeBSD 4.4 (386 Alpha) also. From
the release notes:
Kernel Changes
The O_DIRECT flag has been added to open(2) and fcntl(2). Specifying this
flag for open files will attempt to minimize the cache effects of reading
and writing.
See:
Here is a revised version of pg_stattuple, which shows how many tuples
are dead etc. Per Tom's suggestion, a statistic of free/resuable
space is now printed.
test=# select pgstattuple('accounts');
NOTICE: physical length: 39.06MB live tuples: 10 (12.59MB, 32.23%) dead tuples:
20
Tatsuo Ishii [EMAIL PROTECTED] writes:
This is really annoying since:
o these code fragments actually controls the optimization efforts for
subqueries and views, not related to GEQO at all. So using GEQO
parameters for this kind of purpose seems abuse for me.
But GEQO_RELS is directly
Looks like a good project for 7.3
Probably the best starting point would be to develope contrib/unicode
with smooth transition to core.
Oleg
On Mon, 24 Sep 2001, Patrice [iso-8859-15] Hédé wrote:
Hi all,
while working on a new project involving PostgreSQL and making some
tests, I
I see that
SELECT (time '00:00', interval '1 hour')
OVERLAPS (time '01:30', interval '1 day') AS False;
(a case in the regression tests) returns false (currently labeled as
returning true, but that is another issue ;).
istm that this *should* return true, since times do wrap around the
Well, O_DIRECT has finally made it into the Linux kernel. It lets you
open a file in such a way that reads and writes don't go to the buffer
cache but straight to the disk. Accesses must be aligned on
filesystem block boundaries.
Is there any case where PG would benefit from this? I can see
Unfortunately, some of the head aches I have been encountering require me to
be able to do such oddities (example: my money column type not working with
the pgsql odbc driver). It's not just limited to a varchar to int
conversion that was just an example. There's a bunch of things that I need
I would like to see SQL99's charset, collate functionality for 7.3 (or
later). If this happens, current multibyte implementation would be
dramatically changed...
I'm *still* interested in working on this (an old story I know). I'm
working on date/time stuff for 7.2, but hopefully 7.3 will see
17 matches
Mail list logo
