Tom Lane wrote:
Vinay Jain <[EMAIL PROTECTED]> writes:
Not actually even in Hindi Locale the output was incorrect..i.e. sort
order was wrong
and also length and substring operations
which are not based on syllables.
Hm, possibly you weren't using the same character set encoding that the
l
FireBird: ALTER COLUMN TYPE
DB2:ALTER COLUMN SET DATA TYPE .
Oracle: MODIFY
MSSQL: ALTER COLUMN
MySQL: Both Oracle and MSSQL
Sap:MODIFY
Given that, I'm happy with what we got ...
Yeah same, I was just wondering whether it should be like SET NOT NULL,
that's all.
Chris
-
> I did say we needed more docs effort
Yes, where should the docs for this go? The Alter table reference page,
or Chapter 5.5 titled "Modifying Tables"?
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
Rod Taylor <[EMAIL PROTECTED]> writes:
>>> Also, should the syntax be SET TYPE, not just TYPE?
>> Shrug ... I dunno whether Rod had a precedent for that choice or not.
> FireBird: ALTER COLUMN TYPE
> DB2: ALTER COLUMN SET DATA TYPE .
> Oracle: MODIFY
> MSSQL:ALTER COLUMN
>
> > Also, should the syntax be SET TYPE, not just TYPE?
>
> Shrug ... I dunno whether Rod had a precedent for that choice or not.
FireBird: ALTER COLUMN TYPE
DB2:ALTER COLUMN SET DATA TYPE .
Oracle: MODIFY
MSSQL: ALTER COLUMN
MySQL: Both Oracle and MSSQL
Sap:MODIFY
Spec: No
Tom,
I have included a pg_dump of the schema that causes this problem. If you take out the
word "CROSS" from my source files, it should load just fine. If you then pg_dump it,
in there you should find "CROSS".
Jonathan Scott
On Thu, 06 May 2004 22:26:13 -0400
Tom Lane <[EMAIL PROTECTED]> wrot
Jonathan Scott <[EMAIL PROTECTED]> writes:
> I have included a pg_dump of the schema that causes this problem. If
> you take out the word "CROSS" from my source files, it should load
> just fine. If you then pg_dump it, in there you should find "CROSS".
Indeed, I had just come to the conclusion th
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Just a note for the hackers, Jonathan (I think :) ) talked to me about
> this on the irc channel - we couldn't figure this one out. Seems that
> pg_dump produces NATURAL CROSS JOIN in the dump of a view, but the pgsql
> grammar does not appe
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> What happens with ordering of operations in the ALTER TABLE statement?
> Like if I put an alter TYPE and a SET STORAGE in the same statement
> (wiht commas between), in what order will things happen?
The "right thing" will happen --- in this
I have discovered a problem with psql 7.3.4 where it does not seem to like statements containing "NATURAL CROSS JOIN". I have a test that I have created that will show the problem. Please have a look at it, give it a try, and let me know if there is a problem with the program or with the operator.
I left the statistic setting as-is (do you think that's wrong?) but the
storage spec gets reset to whatever the default for the new type is.
Seems reasonable.
We could talk about doing something more complicated, such as "keep the
old setting if both old and new types support toasting, else reset t
(login_time at time zone 'GMT')::date
but upon experimenting I see that that isn't considered immutable either
:-(. Offhand I think this may be an oversight --- I can't see any reason
for the various flavors of AT TIME ZONE (a/k/a timezone() function)
not to be considered immutable. (Hack
Hi Umberto,
If you are interested in doing any development work on PostgreSQL, you
_really_ need to work from the CVS version :)
Chris
Umberto Zappi wrote:
Thanks to everybody has reply to my email.
Stop immediatly my work in progress.
Some days ago I've downloaded version 7.4.3 of postgresql and
Over the next few months, we will be enabling the following features (all
of which currently have some bugs)
-- Code Snippets: A library to share small scripts and functions,
like Roberto's old "PL/pgSQL Library", but supporting multiple
languages;
-- lightweight personal blo
Hello,
I have discovered a problem with psql 7.3.4 where it does not seem to like statements
containing "NATURAL CROSS JOIN". I have a test that I have created that will show the
problem. Please have a look at it, give it a try, and let me know if there is a
problem with the program or with the
Is it feasible or practical to consider adding ALTER DOMAIN TYPE type?
(basically following the same rules as ALTER TABLE).
I was _just_ about to ask that!
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> consider that login_time is a TIMESTAMPTZ with an index on it.
> test# create index idx on user_logs ( (login_time::date) );
> ERROR: functions in index expression must be marked IMMUTABLE
> why that cast is not considered IMMUTABLE ?
Because it depe
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Out of interest what happens to other column features such as the
> existing statistics level and the existing storage spec? I guess these
> might have to change when type changes??
I left the statistic setting as-is (do you think that's wro
I tweaked things so that the clustered flag is preserved for indexes
that aren't directly affected by the ALTER TYPE. It would take more
work to preserve the setting for an index that is rebuilt by ALTER TYPE,
and I'm not even sure that it's sensible --- the new index could have
a significantly di
- Original Message -
From: "Ismail Kizir" <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
Sent: Friday, May 07, 2004 2:22 AM
Subject: Re: [HACKERS] Fixing the Turkish problem
> Tom,
>
> Thank you very much for turkish locale fix.
> I think, that simple approach will fix the proble
> > nspacl = aclitems_switch_grantor(nspacl, datdba)
>
> Instead of having a hard coded list of template1 objects that need to be
> chowned to the database owner. Perhaps there should be a special user like
> dbowner which owns the schema and whatever other objects are necessary.
> [...]
On Fri, May 07, 2004 at 12:31:51AM +0200, Umberto Zappi wrote:
> Thanks to everybody has reply to my email.
> Stop immediatly my work in progress.
>
> Some days ago I've downloaded version 7.4.3 of postgresql and I've begin
> to work over without know other jobs of other developers :-o
You s
Fabien COELHO <[EMAIL PROTECTED]> writes:
> I agree with the advantage.
>
> But I'm uneasy to know what a special owner would be, pratically speaking.
> If it would mean that everywhere in the source code where an owner is
> manipulated, there must be some kind of special test for that case, I'm
Dear Greg,
> > I agree with the advantage.
> >
> > But I'm uneasy to know what a special owner would be, pratically speaking.
>
> Well I can't think of anywhere else in the code that would need this special
> case other than creating a database.
I disagree, there are consequences. That could be
PostgreSQL's new collaboration site for associated projects, pgFoundry,
also known as projects.postgresql.org, is up and running at
http://www.pgfoundry.org/. This is the beginning of our transition from
our own GBorg to a framework which is maintained and improved by a broad
external community -
Thanks to everybody has reply to my email.
Stop immediatly my work in progress.
Some days ago I've downloaded version 7.4.3 of postgresql and I've begin
to work over without know other jobs of other developers :-o
Bye
Umberto
Umberto Zappi wrote:
I wish modify COPY command for support of CSV
Thomas Hallgren wrote:
> I have a minor problem. I'd like to use the Makefile.shlib that comes with
> PostgreSQL when creating the pljava.dll. Due to the way native methods are
> linked in Java, I need to use the dlltool option "--add-stdcall-alias" when
> I create the dll definition file. In the M
Sorry, this was 7.4 beta 3 ( I was upgrading one test database from 7.4 beta
3, pg_restore was version 7.4.2).
You are right, fn_chk_doc_id is bool type.
However I'll try to dump upgraded database with a new version of pg_dump and
let You know.
Sorry again :-(
Regards !
- Original Message --
I have a minor problem. I'd like to use the Makefile.shlib that comes with
PostgreSQL when creating the pljava.dll. Due to the way native methods are
linked in Java, I need to use the dlltool option "--add-stdcall-alias" when
I create the dll definition file. In the Makefile.shlib, the dlltool for
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> If you do this I suggest supporting bigint as well.
Well I'm not about to actually do the inter-data-type hash joins. I was just
asking if the hash functions for floats should be adjusted to guarantee this
property. bigints already guarantee it, thoug
On Thu, 6 May 2004, Tom Lane wrote:
> sdv mailer <[EMAIL PROTECTED]> writes:
> > The point is pre-forking can *potentially* speed up
> > connections by 5x as shown in this simplistic
> > non-conclusive benchmark.
>
> I think this "benchmark" proves no such thing.
>
> The thing that pgpool is doi
Robert Treat <[EMAIL PROTECTED]> writes:
> What about rules/views/functions and who knows what else (domains?)
> might be dependant on the current type definition?
Yeah, I was just thinking about that this morning. We probably ought to
look for dependencies on the table rowtype as well as the ind
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If we were willing to abuse the ALTER TABLE syntax some more, it would
>> be possible to support changing the datatypes of f1 and f2
>> simultaneously, thereby allowing the above to work.
> Just a clarification: isn't ALTER DOMAIN t
Tom Lane writes:
... too much flushing ...
I agree. I'll bet replacing the pool_write_and_flush() calls in
BinaryRow()
and AsciiRow() with just pool_write(), followed by removing the
fflush() calls at the bottom of those two methods should go a long
way towards fixing things, since the Com
> If we were willing to abuse the ALTER TABLE syntax some more, it would
> be possible to support changing the datatypes of f1 and f2
> simultaneously, thereby allowing the above to work. The infrastructure
> for hacking multiple tables in parallel is already there in CVS tip,
> but it only gets e
On Thursday 06 May 2004 11:47, scott.marlowe wrote:
> On Thu, 6 May 2004, Richard Huxton wrote:
> > Bruce Momjian wrote:
> > > Tom Lane wrote:
> > >>Richard Huxton <[EMAIL PROTECTED]> writes:
> > >>>Does that mean I'll want to disable triggers while I do this?
> > >>
> > >>Hrm. Right now the code
Tom Lane wrote:
> If we were willing to abuse the ALTER TABLE syntax some more, it would
> be possible to support changing the datatypes of f1 and f2
> simultaneously, thereby allowing the above to work. The
infrastructure
> for hacking multiple tables in parallel is already there in CVS tip,
> bu
On May 6, 2004, at 1:06 PM, sdv mailer wrote:
I compared against both TCP and UNIX direct
connections. No SSL, no authentication. See benchmark
results posted below again:
I recall your script only connected 20 times - that is not enough to
filter out "noise" in those numbers. Please run it again
Tom,
You're correct about the test measuring a hot backend
and not forking. How much exactly is the "bulk of the
startup" done by cache initialization relative to the
forking? What would be the impact on Win32 knowing
that process creation is twice as slow than on Linux?
Rod Taylor <[EMAIL PROTECTED]> writes:
>> With your potential changes, you would then be able to alter a domain
>> that is involved in RI constraints between 2 or more tables without
>> bringing down the constraints, yes? This would be great :)
> I had been hoping to get away without actually rec
James Robinson <[EMAIL PROTECTED]> writes:
> Quick overview of the code for differences in TCP-on-the-frontend code
> is a call to setsockopt(..., TCP_NODELAY, ...) if the connection to the
> frontend is a TCP socket. Could this be producing pseudo-fragmentation,
> resulting in over-the-top cont
sdv mailer <[EMAIL PROTECTED]> writes:
> The point is pre-forking can *potentially* speed up
> connections by 5x as shown in this simplistic
> non-conclusive benchmark.
I think this "benchmark" proves no such thing.
The thing that pgpool is doing is not preforking connections at all, but
re-using
Bruce Momjian wrote:
Merlin Moncure wrote:
Is it feasible or practical to consider adding ALTER DOMAIN TYPE type?
(basically following the same rules as ALTER TABLE).
I don't mind bringing down all the views before I do this, it would be
just great if you could change domains from a centraliz
> Yes. This is something I was going to look at doing in the next
release.
Quick question:
With your potential changes, you would then be able to alter a domain
that is involved in RI constraints between 2 or more tables without
bringing down the constraints, yes? This would be great :)
Merlin
On Thu, 2004-05-06 at 13:23, Merlin Moncure wrote:
> > Yes. This is something I was going to look at doing in the next
> release.
>
> Quick question:
> With your potential changes, you would then be able to alter a domain
> that is involved in RI constraints between 2 or more tables without
> bri
Quick overview of the code for differences in TCP-on-the-frontend code
is a call to setsockopt(..., TCP_NODELAY, ...) if the connection to the
frontend is a TCP socket. Could this be producing pseudo-fragmentation,
resulting in over-the-top context switches? Looks like
pool_process_query() does
> > Is it feasible or practical to consider adding ALTER DOMAIN TYPE type?
> > (basically following the same rules as ALTER TABLE).
>
> Interesting --- you would have to rebuild every table that uses the
> domain, and map from-to for all stored values of the domain.
>
> TODO item?
Yes. This i
Nope. I commented out that block of code at 372 and no
difference.
__
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
---(end of broadcast)--
I compared against both TCP and UNIX direct
connections. No SSL, no authentication. See benchmark
results posted below again:
Direct
--
0.144 sec. Client <--UNIX--> PG
0.152 sec. Client <--TCP--> PG
5x Faster
-
0.027 sec. Client <--UNIX--> Pgpool <--UNIX--> PG
0.028 sec. Client <--UNI
Bruce Momjian <[EMAIL PROTECTED]> writes:
> At a minimum, we should indicate we dropped the cluster on the index.
[shrug] If you're going to make me do that, I might as well reinstall
the bit on the new index. The code's problem is it doesn't know that
any of the indexes it dropped were clustered
On May 6, 2004, at 12:19 PM, sdv mailer wrote:
15x Slower:
---
Client <--TCP--> PgPool <--UNIX--> PostgreSQL
Client <--TCP--> PgPool <--TCP--> PostgreSQL
5x Faster:
--
Client <--UNIX--> PgPool <--UNIX--> PostgreSQL
Client <--UNIX--> PgPool <--TCP--> PostgreSQL
If the problem were in
The speedup (UNIX) and slowdown (TCP) are both
compared against normal direct connections from Client
to PostgreSQL. This means with Pgpool (UNIX) it is 5x
faster than normal connections to PostgreSQL. It is
also 15x slower with Pgpool (TCP) compared to normal
connections to PostgreSQL.
My guess i
No SSL. No authentication either. Just friendly
handshakes.
__
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
---(end of broadcast)-
sdv mailer wrote:
>Hi Bruce,
>
>Sorry for the confusion because Rod asked a question
>and I answered too quickly. This is what I mean.
>
>15x Slower:
>---
>Client <--TCP--> PgPool <--UNIX--> PostgreSQL
>Client <--TCP--> PgPool <--TCP--> PostgreSQL
>
>5x Faster:
>--
>Client <--UNIX-
sdv mailer wrote:
> The speedup (UNIX) and slowdown (TCP) are both
> compared against normal direct connections from Client
> to PostgreSQL. This means with Pgpool (UNIX) it is 5x
> faster than normal connections to PostgreSQL. It is
> also 15x slower with Pgpool (TCP) compared to normal
> connecti
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > At a minimum, we should indicate we dropped the cluster on the index.
>
> [shrug] If you're going to make me do that, I might as well reinstall
> the bit on the new index. The code's problem is it doesn't know that
> any of the index
On Thu, May 06, 2004 at 10:17:31 -0400,
Rod Taylor <[EMAIL PROTECTED]> wrote:
> > CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT
> > nextval('doc.seq_doc_id'::text)
> > CONSTRAINT cnst_chk_doc_id CHECK ( fn_chk_doc_id(VALUE) ) ;
> >
> > I did not notice any similar error report on the
Tom Lane wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > 1. alter table alter type on a clustered index seems to drop the cluster
>
> I tweaked things so that the clustered flag is preserved for indexes
> that aren't directly affected by the ALTER TYPE. It would take more
> work to pres
sdv mailer wrote:
> Hi Bruce,
>
> Sorry for the confusion because Rod asked a question
> and I answered too quickly. This is what I mean.
>
> 15x Slower:
> ---
> Client <--TCP--> PgPool <--UNIX--> PostgreSQL
> Client <--TCP--> PgPool <--TCP--> PostgreSQL
>
> 5x Faster:
> --
> Cli
Rod Taylor <[EMAIL PROTECTED]> writes:
>> CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT
>> nextval('doc.seq_doc_id'::text)
>> CONSTRAINT cnst_chk_doc_id CHECK ( fn_chk_doc_id(VALUE) ) ;
> It comes out right for me in 7.4.2.
AFAICT the relevant fix was well before 7.4 release:
2003-10-04 1
Merlin Moncure wrote:
> Is it feasible or practical to consider adding ALTER DOMAIN TYPE type?
> (basically following the same rules as ALTER TABLE).
>
> I don't mind bringing down all the views before I do this, it would be
> just great if you could change domains from a centralized location.
>
Hi Bruce,
Sorry for the confusion because Rod asked a question
and I answered too quickly. This is what I mean.
15x Slower:
---
Client <--TCP--> PgPool <--UNIX--> PostgreSQL
Client <--TCP--> PgPool <--TCP--> PostgreSQL
5x Faster:
--
Client <--UNIX--> PgPool <--UNIX--> PostgreSQL
Tom Lane wrote:
> I tweaked things so that the clustered flag is preserved for indexes
> that aren't directly affected by the ALTER TYPE. It would take more
> work to preserve the setting for an index that is rebuilt by ALTER
TYPE,
> and I'm not even sure that it's sensible --- the new index could
sdv mailer wrote:
> Pgpool connects to PostgreSQL on UNIX socket. I also
> ran on TCP socket but there is no significant
> difference if I recall correctly due to the inherent
> nature of connection pooling or pre-fork technology.
> ;-)
I am confused. First you said TCP was slower, but now you s
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> 1. alter table alter type on a clustered index seems to drop the cluster
I tweaked things so that the clustered flag is preserved for indexes
that aren't directly affected by the ALTER TYPE. It would take more
work to preserve the setting for an inde
Is it feasible or practical to consider adding ALTER DOMAIN TYPE type?
(basically following the same rules as ALTER TABLE).
I don't mind bringing down all the views before I do this, it would be
just great if you could change domains from a centralized location.
Oracle offers this feature...
Me
On Thu, 6 May 2004, Richard Huxton wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >
> >>Richard Huxton <[EMAIL PROTECTED]> writes:
> >>
> >>>Does that mean I'll want to disable triggers while I do this?
> >>
> >>Hrm. Right now the code does not fire triggers at all, but that seems
> >>wrong
Pgpool connects to PostgreSQL on UNIX socket. I also
ran on TCP socket but there is no significant
difference if I recall correctly due to the inherent
nature of connection pooling or pre-fork technology.
;-)
--- Rod Taylor <[EMAIL PROTECTED]> wrote:
> > However, when I tried TCP socket, Pgpool
> However, when I tried TCP socket, Pgpool was actually
> slower by 15x !! Perhaps you can clarify why the TCP
> socket is so much slower?
How did you have pgpool configured to connect to the database? Domain
socket or tcpip?
---(end of broadcast)-
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: 06 May 2004 15:49
> To: Dave Page; [EMAIL PROTECTED]
> Subject: RE: [pgsql-hackers-win32] pg_autovacuum Win32 service patch
>
> Hi!
>
> A few quick comments:
> 1a) Please don't use such a long name for event
> "sdv" == sdv mailer <[EMAIL PROTECTED]> writes:
sdv> Yes, I realize it's a bit old but I just wanted to make a
sdv> small point that forking is slower. It's funny you should ask
sdv> because thread creation on Linux has in fact improved over
sdv> process creation much more in
Ok, I did some benchmark on my Linux box (AMD 1.2Ghz,
256MB, Fedora Core 1 Linux 2.4.20-8) using Pgpool 1.2
and PostgreSQL 7.4. I ran the benchmark script
repeatedly (10+ times each).
I get 5x faster using Pgpool on UNIX socket, which is
encouraging. This shows pre-fork does speed things up
even w
Tatsuo,
I did some benchmark on my Linux box (AMD 1.2Ghz,
256MB, Fedora Core 1 Linux 2.4.20-8) using Pgpool 1.2
and PostgreSQL 7.4. I ran the benchmark script
repeatedly (10+ times each).
I get 5x faster using Pgpool on UNIX socket, which is
encouraging. This shows pre-fork does speed things up.
Joe Conway wrote:
I think you're misinterpreting the docs. The CALL keyword has not been
implemented in Postgres AFAIK. Where precisely did you see that?
Can't find it any more. I'm pretty sure I read it somewhere. Doesn't matter.
I don't see that as a problem.
It is THE problem as far as impleme
Vinay Jain <[EMAIL PROTECTED]> writes:
> Not actually even in Hindi Locale the output was incorrect..i.e. sort
> order was wrong
> and also length and substring operations
> which are not based on syllables.
Hm, possibly you weren't using the same character set encoding that the
locale was expect
If you do this I suggest supporting bigint as well.
On Tue, May 04, 2004 at 06:45:37PM -0400, Greg Stark wrote:
>
> Regarding inter-data-type hash joins, would it make sense to make float
> datatypes to hash to the same value as integral data types for integral
> values?
>
> Conveniently this wo
Shachar Shemesh wrote:
I think the answer is to implement actual stored procedures (as
opposed to functions, which is what we now have). A stored procedure
call, per SQL99/2003 would look something like:
call sp_my_stored_proc();
(which in MSSQL looks like "exec sp_my_stored_proc()")
The curren
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> OTOH, I wonder if maybe what we previously did w.r.t. TZ didn't work, but
> the timezone libs were smart enough to disregard an empty TZ value.
The code in variable.c clearly does *not* work on machines where
putenv() copies what you hand it :-(. I s
Vinay Jain wrote:
You mean that I should create a static table in C program itself and
use it...if i am not wrong
Ya for the time being i am doing this thing but actually table is
bigger (around 5000 rows with 6 columns)
bigger than what?
also this table is also created and destroyed in each ind
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> 1. alter table alter type on a clustered index seems to drop the cluster
> (by design)?
Hmm. Not by design really, but because it's rebuilding all of the
indexes and that status bit doesn't get passed through. I'll see how
hard it is to fix.
> 2. a
> CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT
> nextval('doc.seq_doc_id'::text)
> CONSTRAINT cnst_chk_doc_id CHECK ( fn_chk_doc_id(VALUE) ) ;
>
> I did not notice any similar error report on the list, so I believe that this
> is not fixed yet ?
It comes out right for me in 7.4.2.
Two very minor points with the new alter table (not sure if they are
even bugs are have already been addressed).
1. alter table alter type on a clustered index seems to drop the cluster
(by design)?
2. alter table cluster on seems to give a strange error message of the
index name is really the na
Part of dump file:
CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT
nextval('doc.seq_doc_id'::text)
CONSTRAINT cnst_chk_doc_id CHECK fn_chk_doc_id(VALUE);
It should look like this:
CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT
nextval('doc.seq_doc_id'::text)
CONSTRAIN
Joe Conway wrote:
Shachar Shemesh wrote:
I guess what I would like to suggest is for the thus far unused "select"
command in PLPGSQL to be used, in some way, to return values outside the
scope of the strict "returns" context. I guess out variables will also
be nice, but that's besides the point.
T
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Did we actually find a current system where it broke with a straight
>> putenv("LC_ALL")?
>
> Well, the Single Unix Spec does not say that that works, and neither
> does the HPUX man page for putenv, so you're going to have a hard time
Andrew Dunstan wrote:
Vinay Jain said:
hi
ya function is declared immutable and strict... also made btree
index..
The docs state this about immutable functions:
IMMUTABLE indicates that the function always returns the same result when
given the same argument values; that is, it does not d
Tom Lane wrote:
Vinay Jain <[EMAIL PROTECTED]> writes:
Which takes a lot of time the reason is that in every indchar_lt
function call SPI connection is made and destroyed...
I cannot imagine how you'd think that that would be practical from a
performance standpoint.
Here is the problem
We're sort of halfway there on coping with the Turkish-locale i-vs-I
problem. I'd like to finish the job for 7.5.
What we presently have is that identifier and keyword downcasing is done
without trusting tolower():
/*
* SQL99 specifies Unicode-aware case normalization, which we don't ye
Vinay Jain said:
> hi
> ya function is declared immutable and strict... also made btree
> index..
The docs state this about immutable functions:
IMMUTABLE indicates that the function always returns the same result when
given the same argument values; that is, it does not do database lookups
or
Vinay Jain <[EMAIL PROTECTED]> writes:
> Which takes a lot of time the reason is that in every indchar_lt
> function call SPI connection is made and destroyed...
I cannot imagine how you'd think that that would be practical from a
performance standpoint.
> Here is the problem which i found in po
Didn't think you'd ever get such a result.
Using JDBC (wich has similar functionality), you don't need to worry about
case on identifiers.
regards,
Thomas Hallgren
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Thomas Hallgren" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> The SPI_fnumber (returns the column number using a name) is case sensitive.
It's supposed to be. If it weren't, how would you cope with a result
that contains both "x" and "X"?
regards, tom lane
---(
Doug McNaught wrote:
[EMAIL PROTECTED] (James Thornton) writes:
Is Postgres always one process per client, or can it spawn additional
processes to parallelise some operations such as a nested loops join
operation?
One process per client connection. Right now there is no spawning of
additional "w
hi
ya function is declared immutable and strict... also made btree index..
one mistake that i was doing that I was using libpq rather than
SPI..but even after using it though no doubt the performance is
increased still not up to the mark
if i use index than it's explain analyze is like this :
On Sun, May 02, 2004 at 10:08:50AM +1200, Oliver Jowett wrote:
> If PREPARE can roll back, the driver must maintain a set of all
> statements that were sucessfully PREPAREd in the current transaction,
> and fix up the corresponding query object state whenever a transaction
> rolls back.
>
> Fro
Bruce Momjian wrote:
Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> writes:
Does that mean I'll want to disable triggers while I do this?
Hrm. Right now the code does not fire triggers at all, but that seems
wrong. However, I doubt that very many triggers could cope with update
events in whic
> > Have you looked at sqlrealy.sourceforge.net? IT looks like it might do
> > what you need.
>
> SQL Relay (and friends) do what I'm looking for in a round about way.
>
> If you put it onto the webservers it would help -- but it would require
> deployment of additional webservers to accommodat
97 matches
Mail list logo