Finger or brain trouble, here is the correction :
NUMBER - INTEGER when transporting schemas from Oracle to Pg.
(This needs a little care - as NUMBER in Oracle has bigger *precision*
than INTEGER in Pg)
Thinking about this a bit more, its probably fine to just substitute
NUMERIC for NUMBER,
Mike Mascari kirjutas L, 04.10.2003 kell 06:32:
2) The query language should be computationally complete. The user
should be able to author complete applications in the language, rather
than the language being a sublanguage.
To me it seems like requiring that one should be able to author
Tom Lane kirjutas R, 03.10.2003 kell 18:34:
Michael Brusser [EMAIL PROTECTED] writes:
But when I doubled the number of backslashes:
SELECT smth. FROM tbl WHERE situation LIKE '%%';
- it actually worked fine.
Backslash is special to both the string-literal parser and the LIKE code.
I see that hr translation for libpq is applied, but not that one for
backend that I send few days ago.
Is there any problem with it ?
Regards !
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Thanks - that's what I ended up doing. Hooray for CLUSTER indexes and
constraints in phpPgAdmin CVS now!
Chris
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
If someone could help me with this, it would be cool. How do I query
the catalogs to find the underlying index
regression=# UPDATE foo SET f2=now() WHERE f1=1;
ERROR: deadlock detected
DETAIL: Process 18122 waits for AccessExclusiveLock on relation 154635 of database
17139; blocked by process 18133.
Process 18133 waits for ShareLock on transaction 6330; blocked by process 18122.
The trouble here is
Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
[EMAIL PROTECTED] (Jean-Luc Lachance) writes:
That's one of the draw back of MVCC.
I once suggested that the transaction number and other house keeping
info be included in the index, but was told to forget it...
It would solve once
- Original Message -
From: Hannu Krosing [EMAIL PROTECTED]
Regarding the dollar-quoting discussions -
Will we be able to write the above query as
SELECT smth. FROM tbl WHERE WHERE situation LIKE $$%\\%$$;
Yes, as I understand it (as long as you remove the one of the WHEREs :-)
but this will be in 7.5, not 7.4, won't it?
Andrew Dunstan wrote:
- Original Message -
From: Hannu Krosing [EMAIL PROTECTED]
Regarding the dollar-quoting discussions -
Will we be able to write the above query as
SELECT smth. FROM tbl WHERE WHERE situation LIKE $$%\\%$$;
Yes,
Hi,
Many of the regression tests are failing on my OSX 10.2.6 machine. I have
put the regression.diffs file here
http://bugs.sghms.ac.uk/downloads/regression.diffs
Has this been seen before?
Thanks
adam
Check her over and let me know if there are any problems ... will do a
full general
The world rejoiced as [EMAIL PROTECTED] (Mike Mascari) wrote:
It's a very provocative read. At a minimum, one can learn what to
avoid with SQL. The language looks neat on paper. Perhaps one day
someone will provide an open source implementation. One could envision
a D project along the same
Bruce Momjian [EMAIL PROTECTED] writes:
Do we move empty index pages to the end before truncation during vacuum
full?
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated about making VAC FULL fix the indexes via REINDEX rather than
indexbulkdelete.
Hannu Krosing [EMAIL PROTECTED] writes:
Regarding the dollar-quoting discussions -
Will we be able to write the above query as
SELECT smth. FROM tbl WHERE WHERE situation LIKE $$%\\%$$;
in 7.4 or is \ still special there ?
We were discussing that for 7.5 not 7.4. But yeah, it would work
Adam Witney [EMAIL PROTECTED] writes:
Many of the regression tests are failing on my OSX 10.2.6 machine. I have
put the regression.diffs file here
http://bugs.sghms.ac.uk/downloads/regression.diffs
Seems to be all
! psql: FATAL: sorry, too many clients already
What did initdb set your
On 4/10/03 5:16 pm, Tom Lane [EMAIL PROTECTED] wrote:
Adam Witney [EMAIL PROTECTED] writes:
Many of the regression tests are failing on my OSX 10.2.6 machine. I have
put the regression.diffs file here
http://bugs.sghms.ac.uk/downloads/regression.diffs
Seems to be all
! psql: FATAL:
On Fri, Oct 03, 2003 at 08:57:49 -0500,
Bruno Wolff III [EMAIL PROTECTED] wrote:
I get the error message below when trying to 'make' current cvs:
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -fpic
-I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils
Adam Witney [EMAIL PROTECTED] writes:
On 4/10/03 5:16 pm, Tom Lane [EMAIL PROTECTED] wrote:
What did initdb set your max_connections to?
From src/test/regress/log/initdb.log
selecting default max_connections... 10
Hm. The parallel regression tests require at least 20. I deliberately
Hm. The parallel regression tests require at least 20. I deliberately
allowed initdb to select values as small as 10 on the theory that
installing and not being able to run the parallel regression tests is
better than not installing at all. Does anyone want to argue the
opposite? Perhaps
Rod Taylor [EMAIL PROTECTED] writes:
Hm. The parallel regression tests require at least 20. I deliberately
allowed initdb to select values as small as 10 on the theory that
installing and not being able to run the parallel regression tests is
better than not installing at all.
Another
The following is still a problem in current cvs (as of 2 hours ago).
Normally I wouldn't bug people about this again this soon, but with talk of
a release candidate next week I wanted to make sure that it wasn't forgotten.
On Sun, Sep 28, 2003 at 20:14:03 -0500,
Bruno Wolff III [EMAIL
When grilled further on (Sat, 4 Oct 2003 12:50:27 -0500),
Bruno Wolff III [EMAIL PROTECTED] confessed:
The following is still a problem in current cvs (as of 2 hours ago).
Normally I wouldn't bug people about this again this soon, but with talk of
a release candidate next week I wanted to make
Darko Prenosil writes:
I see that hr translation for libpq is applied, but not that one for
backend that I send few days ago.
Is there any problem with it ?
It might have gotten caught in my mail filters. I've taken it from the
archives and applied it now.
--
Peter Eisentraut [EMAIL
I have added this to the 7.4 open items list:
Fix pg_dump of CREATE TABLE test (col1 BOOLEAN CONSTRAINT test
CHECK (col1))
---
Bruno Wolff III wrote:
The following is still a problem in current cvs (as of
Bruno Wolff III [EMAIL PROTECTED] writes:
The following is still a problem in current cvs (as of 2 hours ago).
Not any more ;-)
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to
Bruce Momjian [EMAIL PROTECTED] writes:
I have added this to the 7.4 open items list:
Fix pg_dump of CREATE TABLE test (col1 BOOLEAN CONSTRAINT test
CHECK (col1))
Fixed now.
regards, tom lane
---(end of
I said:
Hm. The parallel regression tests require at least 20. I deliberately
allowed initdb to select values as small as 10 on the theory that
installing and not being able to run the parallel regression tests is
better than not installing at all.
Actually, after trying to reproduce the
On 10/2/03 11:34 PM, Hannu Krosing [EMAIL PROTECTED] wrote:
James Rogers kirjutas N, 02.10.2003 kell 23:44:
Not exactly. What you are describing is more akin to partitioning or
hash-organized tables i.e. sorting insert/update tuples to various pages
according to some hash function.
What I
Andrew Dunstan [EMAIL PROTECTED] writes:
I now have a C implementation of initdb, ...
There's a little work still to go (see below), but I'd appreciate some
eyeballs on it to see if I have made any major booboos, or could have
done things better. What's the best way to proceed?
Put it on a
Hannu Krosing [EMAIL PROTECTED] writes:
Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
A while back I outlined how this would have to be done, and for it to
be done efficiently, it would be anything BUT simple.
Could this be made a TODO item, perhaps with your attack plan.
If I
Tom Lane kirjutas L, 04.10.2003 kell 19:07:
Hannu Krosing [EMAIL PROTECTED] writes:
Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
A while back I outlined how this would have to be done, and for it to
be done efficiently, it would be anything BUT simple.
Could this be made a
Tom Lane [EMAIL PROTECTED] writes:
(BTW, on my OS X machine, with out-of-the-box configuration, initdb
selects shared_buffers 400 and max_connections 20. I'm guessing that
you had either a nondefault shared memory limit, or some other process
using shared memory.)
This points out another
James Rogers [EMAIL PROTECTED] writes:
On 10/2/03 11:34 PM, Hannu Krosing [EMAIL PROTECTED] wrote:
What I actually thought I was describing is how CLUSTER should work in a
postgres flavour of MVCC storage ;). Not the CLUSTER command, but the
whole feature.
Yeah, I can see this.
Greg Stark [EMAIL PROTECTED] writes:
Perhaps the shared_buffers should only be set to 50% of the maximum size
probed?
I think it's reasonable to expect the DBA to make any adjustments needed
for changes in environment. Partly this is because I don't see any
defensible way to do otherwise ---
Greg Stark [EMAIL PROTECTED] writes:
So I'm a bit confused about the term Clustering. It seems Postgres uses it
to mean simply ordering the tuple storage within an otherwise normal table.
However in other databases it seems to mean something more complex.
My take is that clustering means not
Anyone see a better way?
Switch everything to mmap and pthreads and dump all this antiquated SysV IPC
and semaphore junk? *DUCK*
You are a brave soult. I salute you.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC
Postgresql support,
Hannu Krosing [EMAIL PROTECTED] writes:
The point I was trying to make was that faster count(*)'s is just a side
effect. If we could (conditionally) keep visibility info in indexes,
I think that's not happening, conditionally or otherwise. The atomicity
problems alone are sufficient reason why
On 10/4/03 2:00 AM, Hannu Krosing [EMAIL PROTECTED] wrote:
If the WHERE clause could use the same index (or any index with
visibility info) then there would be no need for walking through the
tuples in data relation.
the typical usecase cited on [HACKERS] was time series data, where
Excellent idea.
Here's the URL: http://www.dunslane.net/~andrew/Initdb_In_C.html
cheers
andrew
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
Andrew Dunstan [EMAIL PROTECTED] writes:
I now have a C implementation of initdb, ...
There's a little work still to go (see
On Sat, Oct 04, 2003 at 11:41:17AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do we move empty index pages to the end before truncation during vacuum
full?
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated about making VAC FULL fix the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do we move empty index pages to the end before truncation during vacuum
full?
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated about making VAC FULL fix the indexes via REINDEX rather than
On Sat, Oct 04, 2003 at 11:17:09PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do we move empty index pages to the end before truncation during vacuum
full?
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated
Alvaro Herrera [EMAIL PROTECTED] writes:
On Sat, Oct 04, 2003 at 11:41:17AM -0400, Tom Lane wrote:
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated about making VAC FULL fix the indexes via REINDEX rather than
indexbulkdelete.
I can't agree with that idea.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
No. You'd be better off using REINDEX for that, I think.
I guess my point is that if you forget to run regular vacuum for a
month, then realize the problem, you can just do a VACUUM FULL and the
heap is back to a perfect state as if
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
The point I was trying to make was that faster count(*)'s is just a side
effect. If we could (conditionally) keep visibility info in indexes,
I think that's not happening, conditionally or otherwise. The atomicity
problems alone are
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
No. You'd be better off using REINDEX for that, I think.
I guess my point is that if you forget to run regular vacuum for a
month, then realize the problem, you can just do a VACUUM FULL and the
heap is back to a
P O S T G R E S Q L
7 . 4 O P E NI T E M S
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
Changes
---
Fix REVOKE ALL ON FUNCTION error when removing owner permissions
Improve speed of building of constraints
On Sun, 5 Oct 2003, Bruce Momjian wrote:
Improve speed of building of constraints during restore
Did we get consensus on what to do with this, whether we're doing
only the superuser option to not check, only speeding up fk constraint
checks by using a statement instead of the repeated calls,
47 matches
Mail list logo
