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 column TYPE type
DB2:ALTER COLUMN column SET DATA TYPE type.
Oracle: MODIFY column type
MSSQL: ALTER COLUMN column type constraints
MySQL:
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 column TYPE type
DB2: ALTER COLUMN column SET DATA TYPE type.
Oracle: MODIFY column type
MSSQL:
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
FireBird: ALTER COLUMN column TYPE type
DB2:ALTER COLUMN column SET DATA TYPE type.
Oracle: MODIFY column type
MSSQL: ALTER COLUMN column type constraints
MySQL: Both Oracle and MSSQL
Sap:MODIFY column type
Given that, I'm happy with what we got ...
Yeah same, I was just wondering
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
Yes, I realize it's a bit old but I just wanted to
make a small point that forking is slower. It's funny
you should ask because thread creation on Linux has in
fact improved over process creation much more in 2.4
kernel.
Benchmark at IBM shows Linux 2.4 thread creation is
30x faster than process
The SPI_fnumber (returns the column number using a name) is case sensitive.
I think a patch would be appropriate. Either to the documentation that could
state this fact and suggest lowercasing the colname parameter, or to the
code to make it case insensitive. I'd be happy to provide the one
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 which
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.
From
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
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
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
---(end of
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]
Sent:
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
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
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
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
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
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
convincing
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.
This
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)
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
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.
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. alter
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
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
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 current
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 would
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 expecting?
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
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.
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
-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 source.
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 2.4 kernel.
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)---
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 was
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. However, I doubt that
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...
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 index
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 say
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
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
Client
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.
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 14:22
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-- PgPool
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 preserve the
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 list, so I
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 indexes it
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
connections
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-- PgPool --UNIX--
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
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 TCP stack
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,
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 --UNIX--
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
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 is
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()
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
bringing
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
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
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 prior
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 context
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 rechecking
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?
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 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,
but it
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 does not fire triggers
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
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
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 the best
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
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 doing is not
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, though I
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
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
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
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
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
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
not
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
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.
[...]
I
- 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 problem.
And
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
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 wrong?)
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
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
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
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
(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.
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
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.
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 case,
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 appear to
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 that this
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] wrote:
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 depends
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
97 matches
Mail list logo
