(with the assumption they're generally static).
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.
- Original Message -
From
This would be a potential feature of being able to insert into
views
in general. Reversing the CREATE VIEW statement to accept
inserts,
deletes and updates.
Definitely not a 'potential' feature, but a existing and documented
one.
Read up on rules, especially 'ON INSERT DO INSTEAD' stuff.
This would be a potential feature of being able to insert into
views
in general. Reversing the CREATE VIEW statement to accept
inserts,
deletes and updates.
Definitely not a 'potential' feature, but a existing and
documented
one.
Read up on rules, especially 'ON INSERT DO
With stock PostgreSQL... how many committed transactions can one
lose
on a simple system crash/reboot? With Oracle or Informix, the answer
is zero. Is that true with PostgreSQL in fsync mode? If not, does it
lose all in the log, or just those not yet written to the DB?
With WAL the theory is
This is rather like MySQL's enum. I still opt for the join, and if
you like make a view for those who don't want to know the data
structure.
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes
the
hardware till they are a similar speed level. Now you do a price
comparison and take it to business. 'Cheaper software, but slightly
more expensive hardware means a lower priced package with similar
performance'.
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how
/8601.pdf
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise
Makes it more fun :) Kinda like a lottery ticket:
- reliable (cherry)
- fast (cherry)
- resource hog (lemon)
--
Rod Taylor
BarChord Entertainment Inc.
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
To: Martín Marqués [EMAIL PROTECTED]
Cc: Trond Eivind Glomsrød [EMAIL
INTO testlock DEFAULT VALUES:
INSERT INTO testlock DEFAULT VALUES:
INSERT INTO testlock DEFAULT VALUES:
SELECT id FROM testlock WHERE user_write_lock_oid(oid) = '1' LIMIT 1;
-- From another connection
SELECT user_write_lock_oid(oid) FROM testlock;
--
Rod Taylor
BarChord Entertainment Inc.
BEGIN:VCARD
As a general rule I don't. But I'm having a hard time trying to find
out if there is a lock on a given item without attempting to lock it.
Seems to work that way with all locks but most delay until it can
obtain it. Userlocks don't wait.
--
Rod Taylor
BarChord Entertainment Inc
after
using it so that doesn't really affect anything. What I do want
though is the action to become available again if something doesn't
complete.
--
Rod Taylor
BarChord Entertainment Inc.
BEGIN:VCARD
VERSION:2.1
N:Taylor;Rod;B
FN:Taylor, Rod B
ORG:BarChord Entertainment Inc.;System Operation
Corrupted or not, after a crash take a snapshot of the data tree
before firing it back up again. Doesn't take that much time
(especially with a netapp filer) and it allows for a virtually
unlimited number of attempts to solve the trouble or debug.
--
Rod Taylor
BarChord Entertainment Inc
I like this. Ensure that tips can be dumped into a log file --
preferably separate from the main one -- so it can be run on a live
system for a short period of time, recorded then analyzed later.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth
on values which didn't exist in the second
table -- thereby blocking the deletion from the primary or referred
table..
Tried against 7.1beta3 and 7.1beta5.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
- Original Message
;
CREATE TABLE junk (
col int4 NOT NULL REFERENCES junk_parent(col) ON UPDATE CASCADE ON
DELETE CASCADE
);
INSERT INTO junk VALUES ('1');
DELETE FROM junk_parent WHERE col = 1;
DELETE FROM junk_parent WHERE col = 2;
--
Rod Taylor
There are always four sides to every story: your side, their side
included for files affected)
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
- Original Message -
From: "Christian Weisgerber" [EMAIL PROTECTED]
Newsgroups: list.vorbis.dev
To: [EMAIL PROTECTED]
Sent: Saturday, Marc
being left
behind it makes SERIAL a pain in the ass. Atleast names for the
sequence are usually predictable.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
BEGIN:VCARD
VERSION:2.1
N:Taylor;Rod;B
FN:Taylor, Rod B
before
appears, and the notice after doesn't.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
BEGIN:VCARD
VERSION:2.1
N:Taylor;Rod;B
FN:Taylor, Rod B
ORG:BarChord Entertainment Inc.;System Operation and Development
TITLE:Chief
() does not exist
temp=#
temp=# DROP FUNCTION dbuser_account(varchar(40), varchar(40),
varchar(40));
DROP
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
BEGIN:VCARD
VERSION:2.1
N:Taylor;Rod;B
FN:Taylor, Rod B
ORG:BarChord
Sorry, Postgres 7.1 beta4
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
- Original Message -
From: "Rod Taylor" [EMAIL PROTECTED]
To: "Hackers List" [EMAIL PROTECTED]
Sent: Tuesday, February 13, 2
alternative.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
BEGIN:VCARD
VERSION:2.1
N:Taylor;Rod;B
FN:Taylor, Rod B
ORG:BarChord Entertainment Inc.;System Operation and Development
TITLE:Chief Technical Officer
ADR;WORK
adow" not found
temp=#
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
BEGIN:VCARD
VERSION:2.1
N:Taylor;Rod;B
FN:Taylor, Rod B
ORG:BarChord Entertainment Inc.;System Operation and Development
TITLE:Chief Technical Officer
not
noticed any problems on the test system thus far).
Thanks for any input.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
BEGIN:VCARD
VERSION:2.1
N:Taylor;Rod;B
FN:Taylor, Rod B
ORG:BarChord Entertainment Inc.;System Operation
My mistake. The index on pg_shadow breaks nearly everything. I can
have triggers maintain this effectively enough for my needs however.
However, whether or not the number of users I want to add is going to
be too much is still a question.
--
Rod Taylor
There are always four sides to every
t;reltriggers" = TMP."tmp_reltriggers" FROM "tr"
TMP WHERE "pg_class"."relname" = TMP."tmp_relname";
DROP TABLE "tr";
COMMIT TRANSACTION;
--
These make importing into other database systems rather difficult.
--
Rod Taylor
There
It was obviously designed with MySQL's "Nobody needs transactions for
webwork" type of situation in mind.
This is interesting. I always wondered how the persistent connection
stuff handled this, and not I see that it doesn't.
[ Charset ISO-8859-1 unsupported, converting... ]
The only
ded devices in assembly or
higher level php / perl.
--Rod Taylor
There are always four sides to every story: your
side, their side, the truth, and what really
happened.
BEGIN:VCARD
VERSION:2.1
N:Taylor;Rod;B
FN:Taylor, Rod B
ORG:BarChord Entertainment Inc.;System Operation and Developmen
Little early aren't you?
select now()::date gives me 2000-12-22
Hmm.. only one digit is odd.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
- Original Message -
From: "Partyka Robert" [EMAIL PROTECTED]
comments.
Didn't have a database handy with the rest, and had a limited amount of time to
fiddle.
Take a look and see if it's worth anything or if it
needs to be fixed up.
--Rod Taylor
There are always four sides to every story: your
side, their side, the truth, and what really
happened
Christopher Kings-Lynne wrote:
I like this conversation as not a day goes by where I don't wish I could
edit the dump of a database rather than keeping structure entirely
seperate -- and actually do so in a useful manner. That said, whats the
possibility of maintaining comments if the
Luis Magaña wrote:
Hi:
Have this curious situation and would like some help from you:
Create an employee table:
CREATE TABLE employee(
id_employee SERIAL PRIMARY KEY,
sex CHAR(1) DEFAULT 'm' CHECK(sex = 'f' OR sex = 'm'),
start_date DATE NOT NULL,
charge VARCHAR(50)
That would be an extreamly good reason then. I suppose I've fallen into
the 'other' standard :(
Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
I believe that the coalesce function can
get you out of this... Speaking of which, why isn't it called NVL()?
Because the SQL92
Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
* disk space --- letting pg_log grow without bound isn't a pleasant
prospect either.
Maybe this can be achieved by wrapping XID for the log file only.
How's that going to improve matters? pg_log is ground truth for XIDs;
if
Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
With the number of cron jobs that run a perl script which runs a simple
SELECT function(); that does various nightly cleanup or maintenance
(billing run) it would be much nicer to have an actual trigger run every
12 hours rather than
901 - 934 of 934 matches
Mail list logo
