I have already this mail to PATCHES mailing list and nobody replied me !!!.,
Hope the hackers and the developers send their ideas.
Qustion: is this approach is suitable for solving the need for locale per column in PostgreSQL ?
There is a function I attached to this mail. this function is
Mahmoud Taghizadeh wrote:
I have already this mail to PATCHES mailing list and nobody replied
me !!!., Hope the hackers and the developers send their ideas.
Qustion: is this approach is suitable for solving the need for locale
per column in PostgreSQL ?
I doubt that, because 1) it's
Oliver Jowett wrote:
BEGIN
SAVEPOINT a
-- work
SAVEPOINT b
-- work
SAVEPOINT a
-- work
ROLLBACK TO b
-- work
This is valid: the standard says that the second SAVEPOINT a destroys
and recreates the savepoint a, but doesn't say that it destroys
intervening savepoints. In
Peter Eisentraut [EMAIL PROTECTED] writes:
2) switching the locale at run time is too expensive when using the system
library.
Fwiw I did some experiments with this and found it wasn't true. At least with
glibc I could switch the locale to what I wanted and back for every record in
a million
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
On the other hand, the scenario of a psql option (read: I have
given up the idea of a backend implementation) to rollback only
last statement on error is quite different.
Sure (and we already have one for autocommit). But I
On 19 Sep 2004, Greg Stark wrote:
don't think that's an argument for postgres to reimplement portions of the OS.
If the OS locale handling is slow on some OS's then postgres should just warn
its users that using locales on those OS's will be slow.
In any case I suspect more than just the
Dennis Bjorklund [EMAIL PROTECTED] writes:
Still, we want the final solution to be what the sql standard specify. A
function as the proposed is however useful until a standard sql solution
is implemented. I've used a similar function for some projects and it have
worked well for me also.
I
Greg Stark [EMAIL PROTECTED] writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
2) switching the locale at run time is too expensive when using the system
library.
Fwiw I did some experiments with this and found it wasn't true.
Really?
I was just in process of doing experiments using the
On Sun, 19 Sep 2004, Greg Stark wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Still, we want the final solution to be what the sql standard specify. A
function as the proposed is however useful until a standard sql solution
is implemented. I've used a similar function for some
Greg Stark [EMAIL PROTECTED] writes:
I don't see how this is relevant though. One way or another postgres is going
to have to sort strings in varying locales chosen at run-time. Comparing
against strcoll's execution time without changing changing locales is a straw
man.
No, it's not, because
On 19 Sep 2004, Greg Stark wrote:
I've seen people describe here I think the standard behaviour will be nigh
useless anyway. From what I understand the standard has you declare a locale
per column.
Yes, you can define a default collation for a column if you want to but
more important you can
Hm, ok, setting up a new database with the Conway implementation I see the
time penalty is not negligible. However it is quite tolerable:
test= explain analyze select * from test order by a;
QUERY PLAN
On 9/17/2004 7:32 PM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
The problem comes and goes. So either I can cause a coredump just on the
snap by running a shellscript that does 100 psql -c select version()
calls, or it is next to impossible to crash it at all.
Hmm, that's really
Mahmoud Taghizadeh wrote:
I have already this mail to PATCHES mailing list and nobody replied
me !!!., Hope the hackers and the developers send their ideas.
Qustion: is this approach is suitable for solving the need for locale
per column in PostgreSQL ?
I doubt that, because 1) it's
On 9/18/2004 8:38 AM, Michael Paesold wrote:
Tom Lane wrote:
There is some debug output available from the ARC code,
but I dunno if its output is actually useful ;-). Try
http://developer.postgresql.org/docs/postgres/runtime-config.html#GUC-DEBUG-SHARED-BUFFERS
debug_shared_buffers (integer)
At 2004-09-17 14:28:36 -0700, [EMAIL PROTECTED] wrote:
Assuming that anyone steps up and does the work, that is.
So...any volunteers?
OK, how about adding a PQprepare (PQcreatePrepared?) function like this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
On Sep 19, 2004, at 9:13 PM, Abhijit Menon-Sen wrote:
OK, how about adding a PQprepare (PQcreatePrepared?) function like
this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
OK, how about adding a PQprepare (PQcreatePrepared?) function like this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid
Hi,
I'm working on running postgresql in a chrooted filesystem.
/src/backend/commands/dbcommands.c makes use of system(3): as far as I
can see, this is only used to execute rm(1) and cp(1). I'd like to avoid
placing /bin/sh in the root of the filesystem (which system() requires).
I see four
At 2004-09-20 01:25:56 -0400, [EMAIL PROTECTED] wrote:
That means you also need to add a new Execute method that takes a
portalName instead of a command.
Yes, thanks. How about these functions, then?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
20 matches
Mail list logo
