Jeffery Collins wrote:
I was wondering if anyone could help me with the following questions.
They are all related to user defined types and functions.
1. Environment variables in function pathname. We would like to
[...]
Create your SQL scripts that define the functions in a make
Tom Lane wrote:
Can one create tables using the perl, C, or TCL interfaces?
Offhand I think this would work out-of-the-box in pltcl and plperl,
because they don't do preplanning. This is also why you can do
something like "SELECT ... FROM $1" in those PLs and not in plpgsql:
they just
Hi there,
I successfully renamed one of the columns of the primary key of one of
my tables (it is used in one of the foreign keys, too -- I think, this
is the problem). Unfortunately, the constraint (rule system?) wasn't
updated by "alter table" -- have a look:
Hello all,
In writing a perl/DBI based application for our customers, we noticed some very
intersting behavoir. Against 2 tables, running a select, when you we do a
WHERE clause with a lot of items in it ... the query is fast. When we do it
with just one or two items, its hugely slower! Enough
Ulf Mehlig wrote:
Hi there,
I successfully renamed one of the columns of the primary key of one of
my tables (it is used in one of the foreign keys, too -- I think, this
is the problem). Unfortunately, the constraint (rule system?) wasn't
updated by "alter table" -- have a look:
Hello,
with pg_dump testdb db.out there is an errorline
getTypes(): SELECT failed. Explanation from backend: 'ERROR: cache
lookup for
userid 201 failed
any Idea
marc
alter table cust add constraint fk_cust_bd_id foreign key (bd_id)
references bill_dist (bd_id);
At 12:57 PM 7/26/00 -0700, Timothy H. Keitt wrote:
Can someone give an example of how to add a foreign key constraint to an
existing table? (Pgsql and the man page differ and neither syntax
hello,
after one has put a foreign key constraint on a table,
how can one drop that constraint???
mikeo
Hmmm... I got it to work, but using a slightly different syntax. Let me
see if I understand your example:
ALTER TABLE
cust# the table to be altered
ADD CONSTRAINT
fk_cust_bd_id # the column in cust to add the constraint?
FOREIGN KEY
(bd_id)
Ian Turner [EMAIL PROTECTED] writes:
Looking at the source, I see the following parsenodes which are NOT
supported by copyObject:
Uh, what version of the source are you looking at? Quite a few of
those *are* supported.
Which of these is it worth supporting? I will implement the necessary
almost,
ALTER TABLE
cust# the table to be alteredyes
ADD CONSTRAINT
fk_cust_bd_id # name of the constraint (see
tgconstrname column in pg_trigger)
FOREIGN KEY
(bd_id) # column in cust to be FK'd to
Ernie [EMAIL PROTECTED] writes:
Here's an explain on the above query:
Um, *which* query was that for? And what's the EXPLAIN output for
the other query?
regards, tom lane
It would seem that it wouldn't break anyone's existing setup, since
you couldn't have an env variable in there anyway. (No one really
has a directory called $HOME, I hope!)
So, perhaps it could just be something in the documentation that
has a stern warning about watching your consistency.
Tom Lane wrote:
Jeffery Collins [EMAIL PROTECTED] writes:
what is the proper way to build a patch file that
contains the changes? I have never done this before.
"diff -c" against current sources, done so that the correct file
pathnames are visible in the diff output; that is, cd to top
THe implications of the OIDs not wrapping are immense. We have some extremely
active databases that will easily reach this limit in two or three years. For
some applications, such as ecommerce, dumping then reinserting the rows is
not an option for large databases due to the 24 hours nature of
Simply waiting for 64bit numbers is rather inelegant and also
presumes usage
parameters for the database... remember Bill Gates saying that he couldn't
foresee any usage for more than 64MB of RAM?
I've heard this before and I just don't agree. 64MB ram, perhaps, but who
is going to need 64
Tom Lane wrote:
Paul Caskey [EMAIL PROTECTED] writes:
Tom Lane wrote:
It's only a hard limit if your application assumes OIDs are unique.
If you don't assume that, then I think it's not a big problem.
It's possible (though obviously not especially likely) that you might
get OID
Paul Caskey [EMAIL PROTECTED] writes:
No doubt about it, you're likely to get a few "duplicate key" errors and
stuff like that. I'm just observing that it's not likely to be a
complete catastrophe, especially not if you don't rely on OIDs to be
unique in your user tables.
I don't rely on
brad [EMAIL PROTECTED] writes:
snip
Simply waiting for 64bit numbers is rather inelegant and also presumes usage
parameters for the database... remember Bill Gates saying that he couldn't
foresee any usage for more than 64MB of RAM? Besides which, PostgreSQL is the
best DB around... there's
Ummm ... I'm a newbie to this list, but hasn't this evolved into a hacker
issue?
Also, Bill Gates said something along the lines of nobody will ever need
more than 640KB of RAM ... which was the usable limit on the old XT's
(remember them :) in the early MS-DOS days :)
Dave Burbidge
Network
On Thu, 27 Jul 2000, Dave Burbidge wrote:
Also, Bill Gates said something along the lines of nobody will ever need
more than 640KB of RAM ... which was the usable limit on the old XT's
(remember them :) in the early MS-DOS days :)
Actually, I think the quote is an urban legend.
Brett W.
The Versant ODBMS uses 48 bit oids, and if you do the math I think
you'll find that should last you forever. (It uses an additional 16 bits
to identify the database, but that's another story.).
Any complex scheme to solve this seems like a waste of time. In a couple
of years when you are likely
22 matches
Mail list logo
