Hello again,
I turn the discussion to the dev list as it seems more appropriate.
So about the proposed patch to warn if foreign key type do not match the
target key:
Stephan Szabo [EMAIL PROTECTED] writes:
I'm really not sure that it makes sense to warn for the fk cases where the
Chad kirjutas R, 27.02.2004 kell 14:53:
Is it possible for Postgres Btrees to support access by logical row number ?
WHat do you mean by logical row number ?
Hannu
---(end of broadcast)---
TIP 7: don't forget to increase your free
Marc G. Fournier [EMAIL PROTECTED] writes:
sizes all look about right, if someone wants to download and confirm?
The full gz and bz2 tarballs match what I have here. Didn't check the
partial tarballs.
I have tested postgresql-7.3.6.tar.gz. All regression tests
passed. This is Linux Kernel
I can find rpms for rh8, rhel 3 but not rh9; is there some reason why
they aren't necessary? Are rhel 3 binaries compatible with rh9?
--
Dave Cramer
519 939 0336
ICQ # 14675561
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 2 Mar 2004, Dave Cramer wrote:
I can find rpms for rh8, rhel 3 but not rh9; is there some reason why
they aren't necessary? Are rhel 3 binaries compatible with rh9?
Yes, you can install rhel3 binaries on rh9.
Regards,
- --
Devrim GUNDUZ
but on postgres ftps mirrors are only full-packet, -base, -dosc, -opt, and
-test , where can be -devel or -libs ? ( use -base ? )
On Mon, 1 Mar 2004, Martin Marques wrote:
El Lun 01 Mar 2004 11:11, ivan escribió:
hi,
is there same packets (or sources to compile) only for client-systems
On Monday 01 March 2004 22:59, Curt Sampson wrote:
On Mon, 1 Mar 2004, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
Can you explain how to do this? There is no reference to a plan in the
contract table; the constraint just checks to see that, if a contract
exists, there is at
On Tue, 2 Mar 2004, Fabien COELHO wrote:
Hello again,
I turn the discussion to the dev list as it seems more appropriate.
So about the proposed patch to warn if foreign key type do not match the
target key:
Stephan Szabo [EMAIL PROTECTED] writes:
I'm really not sure that it makes
Hello Stephan,
CREATE TABLE foo(fid INT4 NOT NULL PRIMARY KEY, ...);
CREATE TABLE bla(fid INT2 REFERENCES foo, ...);
The application will be fine till you enter fid=32767, and
it inserts will fail in bla with fid=32768. Much later on.
Which is fine if bla is meant to store a subset
Tom Lane wrote:
I don't have a strong opinion about IN array, but am worried that
allowing it would create ambiguity about which interpretation is meant.
Is the left-hand side supposed to be compared against the whole array or
each array member?
That was exactly the problem. IN (array) does work
On Tue, 2 Mar 2004, Fabien COELHO wrote:
Hello Stephan,
CREATE TABLE foo(fid INT4 NOT NULL PRIMARY KEY, ...);
CREATE TABLE bla(fid INT2 REFERENCES foo, ...);
The application will be fine till you enter fid=32767, and
it inserts will fail in bla with fid=32768. Much later on.
On Tue, Mar 02, 2004 at 09:45:03 -0500,
Robert Treat [EMAIL PROTECTED] wrote:
Wouldn't a FK on both tables be the appropriate schema? With the FK on
contract being deffered?
No, since he only cares that there is at least one plan for a contract,
not a particular plan. You can do something
Dear Stephan,
Although it is POSSIBLE that this is fine, it is much more PROBABLE that
it is a bug, hence I just suggest to issue a mere simple basic plain
user-friendly little warning, what is quite different from issuing an
error. [...] Why not allowing that kind of approach in
Greg Patnude [EMAIL PROTECTED] writes:
It would be really sweet in postgreSQL if we could apply the
equivalent of a printf(columnname) to the table definition -- MS
Access has what they call an input mask and it comes in really
handy -- however -- I havent used Access for anthing serious for
Christopher Kings-Lynne wrote:
Why? You can reconstruct it with a simple ANALYZE command. Dumping
and restoring would mean nailing down cross-version assumptions about
what it contains, which doesn't seem real forward-looking...
I seem to recall that people like that kind of thing so
Tom Lane wrote:
Jonathan Scott [EMAIL PROTECTED] writes:
I checked my system, and bison is reporting itself as 1.875. I am using SuSE 9.0,
and I did have to upgrade to get that configuration message to go away, AND to
make it compile.
Could you recommend a way I could get bison to
On Tue, 2 Mar 2004, Joe Conway wrote:
regression=# select 1 where array[1] in (array[1]);
?column?
--
1
(1 row)
regression=# select 1 where array[1] in (array[1,2]);
?column?
--
(0 rows)
The only reason I brought it up was that to me ANY and IN are pretty
Dennis Bjorklund wrote:
The only reason I brought it up was that to me ANY and IN are pretty much
the same kind of operator. Up until now I thought that IN really was the
same as =ANY, but it isn't. I don't like that but of course I have to
accept it. I would rather have had some elem
Joe Conway [EMAIL PROTECTED] writes:
But then we need to decide, what happens when we see:
argL IN (argR1, argR2, ...)
and argRn data type is an array of argL data type? Do we check all the
argRn elements individually and return true if any of them equal argL?
I'd guess so.
This seems
Tom Lane wrote:
[ wanders away trying to remember that quote about foolish consistency ]
http://www.bartleby.com/59/3/foolishconsi.html
A foolish consistency is the hobgoblin of little minds
A great person does not have to think consistently from one day to the
next. This remark comes from the
Tom Lane [mailto:[EMAIL PROTECTED]
Simon Riggs [EMAIL PROTECTED] writes:
You're absolutely right about the not-knowing when you're out of
space
issue. However, if the xlog has been written then it is not
desirable,
but at least acceptable that the checkpoint/bgwriter cannot complete
on
an
On Tue, 2 Mar 2004, Robert Treat wrote:
Wouldn't a FK on both tables be the appropriate schema? With the FK on
contract being deffered?
Unfortunately, it appears that an FK must reference a unique column. So this:
ALTER TABLE contract ADD CONSTRAINT contract_must_have_a_plan
hi all
Are there any other docs about tsearch2 except for the 3 docs in \contrib\tsearch2\docs
i want some tech docs on tsearch2 thank all
---(end of broadcast)---
TIP 8: explain analyze is your friend
Joe Conway [EMAIL PROTECTED] writes:
I wrestled with the same issue last year.
Offhand I don't know how hard it would be to do, but I wonder if when we see:
argL IN (argR)
we might be able to determine if argL and argR are of the same type or if argR
is an array of argL, and act
A table space parameter will be added to DDL commands which create
physical database objects (CREATE DATABASE/INDEX/TABLE/SEQUENCE) and to
CREATE SCHEMA. The associated routines, as well as the corresponding DROP
commands will need to be updated. Adding the ability to ALTER object
TABLESPACE name
How easy is to to get cursor access to the indexes and fine grained
control of the transaction system, are their fairly clean internal
APIs I can leverage.
I'm not sure 'PostgreSQL' and 'fairly clean internal API' go together :P
Chris
---(end of
I've been looking at implementing table spaces for 7.5. Some notes and
implementation details follow.
Ah sorry, other things you might need to consider:
Privileges on tablespaces:
GRANT USAGE ON TABLESPACE tbsp TO ...;
Different disk settings for different tablespaces (since they will
likely
I recently had to figure out what was different between the live schema
and the schema in cvs at work. This was a really painful process, and it
occurred to me that it wouldn't be terribly hard to write a perl program
to do it (I wound up using vim and diff). Is there interest in such a tool?
I
Greg Stark [EMAIL PROTECTED] writes:
That would be nice and simple and clean, except that postgres's type system
doesn't work that way. It works backwards from every other language. Instead
of every variable and function return value having a rigid type and forcing
the interpretation of the
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
How about allowing the specification on schemas and databases of
different default tablespaces for TEMP, TABLE and INDEX?? Is there any
point to that?
TEMP tables are not local to any particular schema, so it wouldn't make
sense to have a
Greg Stark wrote:
So in this case if argL or argR are functions or other expressions with
unknown types it tries to figure out how to interpret them to produce the type
it's looking for. In other words, what type those expressions are depends on
what the expression expects. What would you do with
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
Right. This is in fact not a fatal situation, as long as you don't
run out of preallocated WAL space.
Clearly running out of pre-allocated WAL space is likely to be the next
issue. Running out of space in the first place is likely to
Richard Huxton wrote:
On Thursday 26 February 2004 10:07, Gavin Sherry wrote:
CREATE TABLESPACE tbl1 LOCATION '/var/'
which will result in something like '/var/123443' is a bad idea. Then
again, the user should know better. Comments?
The LOCATION should have the same owner and
Joshua D. Drake wrote:
Is it possible to put WALs and CLOGs into different tablespaces? (maybe
different RAID systems). Some companies want that ...
You can do this now, but it would be nice to be able to have it actually
configurable versus the hacked linked method.
Agreed, but because
Uhm. oops. I'll just crawl back under this rock for a bit longer before I
speak on this topic again. sorry.
--
greg
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Tue, 2 Mar 2004, Bruce Momjian wrote:
Gavin Sherry wrote:
The actual creation of the table space will be done with:
CREATE TABLE SPACE name LOCATION /path/to/tblspc;
Seems you should use CREATE TABLESPACE (no space) so it is more distinct
from CREATE TABLE.
Oops. Typo.
--
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
A table space is a directory structure. The directory structure is as
follows:
[EMAIL PROTECTED] /path/to/tblspc]$ ls
OID1/ OID2/
OID1 and OID2 are the OIDs of databases which have created a table space
against this file
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
Speaking of locking, can we do anything to prevent people from shooting
themselves in the foot by changing active tablespaces? Are we even
going to have a DROP TABLESPACE command, and if so what would it do?
Ahh. I forgot to detail
Tom Lane wrote:
One of the things that bothers me about the present PITR design is that
it presumes that individual WAL log segments can be kept until the
external archiver process feels like writing them somewhere. If there's
no guarantee that that happens within X amount of time, then you can't
Greg Stark wrote:
I am expecting to hear some bleating about this from people whose
preferred platforms don't support symlinks ;-). However, if we don't
Well, one option would be to have the low level filesystem storage (md.c?)
routines implement a kind of symlink themselves. Just a
Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
Is possible / reasonable / smart and or dumb to look at implementing the
tablespaces as riding atop the initlocation handled stuff.
In my mind, one of the main benefits of this work will be that we'll be
able to get *rid* of the
Josh Berkus wrote:
#3: ALTER TABLE CHANGE TABLESPACE:
This is strictly in the class of would be a very nice useful feature if
it's not too difficult. ?
Given how painful it is to drop replace a table with multiple dependencies
(on some databases, only possible by droping
Gavin Sherry wrote:
Actually, I think that's a pretty good idea :-). I'd solves a bunch of
issues in the backend (postmaster start up can recurse through
$PGDATA/tablespaces looking for postmaster.pid files) and will also assist
admins with complex configurations (perhaps).
Why are you asking
On Tue, 2 Mar 2004, Bruce Momjian wrote:
Gavin Sherry wrote:
Actually, I think that's a pretty good idea :-). I'd solves a bunch of
issues in the backend (postmaster start up can recurse through
$PGDATA/tablespaces looking for postmaster.pid files) and will also assist
admins with
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
facing the possibility of an out-of-WAL-space panic. I suspect that we
cannot really do anything about that, but it's annoying. Any bright
ideas out there?
Maybe specify an archive location (that of course could be on a separate
Andrew Dunstan wrote:
I haven't had any other feedback on this patch that I posted. However,
I'm a bit dissatisfied with it for a couple of reasons:
. when a connection is logged we don't yet know the user and database,
because we haven't processed the initial packet yet. That causes %U
Gavin Sherry wrote:
On Tue, 2 Mar 2004, Bruce Momjian wrote:
Gavin Sherry wrote:
Actually, I think that's a pretty good idea :-). I'd solves a bunch of
issues in the backend (postmaster start up can recurse through
$PGDATA/tablespaces looking for postmaster.pid files) and will also
Bruce Momjian [EMAIL PROTECTED] writes:
For tablespaces on OS's that don't support it, I think we will have to
store the path name in the file and read it via the backend. Somehow we
should cache those lookups.
My feeling is that we need not support tablespaces on OS's without
symlinks.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
For tablespaces on OS's that don't support it, I think we will have to
store the path name in the file and read it via the backend. Somehow we
should cache those lookups.
My feeling is that we need not support tablespaces on OS's
On Wed, 3 Mar 2004, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
For tablespaces on OS's that don't support it, I think we will have to
store the path name in the file and read it via the backend. Somehow we
should cache those lookups.
My feeling is that we need not support
50 matches
Mail list logo