> Well, that's a good question. Does anyone else have an opinion on
> whether this would be a good/bad/indifferent feature? We've seen
> problems in the past caused by depending on postmaster environment
> variables (restart the postmaster with different environment than
> usual, things mysterio
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
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.
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 A
brad <[EMAIL PROTECTED]> writes:
> 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
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
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 mi
> 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
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 the
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
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. Cav
Jeffery Collins <[EMAIL PROTECTED]> writes:
like the following syntax to work:
>>
CREATE FUNCTION myfunc(mytype) RETURNS text AS
'$HOME/lib/libmyso.so' LANGUAGE 'c':
>>
and have the environment variable $HOME "lazy" evaluated. I
have looked at the fmgr code and this doe
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
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 bil
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 necessar
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)
hello,
after one has put a foreign key constraint on a table,
how can one drop that constraint???
mikeo
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 se
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
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:
>
> --
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 seems
to work.)
I've tried:
alter table mytable add constraint col foreign key references reftable
with no luck.
Tim
--
Timothy H. Keitt
National Center
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
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:
--
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
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
25 matches
Mail list logo
