Hey folks,
I am inserting data into a table with a three-column primary key (the
table is only three columns). The rows I'm trying to insert may very
well be duplicates of ones already in the table, so I would like to have
PostgreSQL handle the insert and possible error resulting from dup dat
> You just have to put it in the select list as a constant. If you're
> feeling
> generous to the next programmer to read it you could put "AS column1"
> after
> each one, but the column name doesn't actually have to match the column
> you're
> inserting into.
Sweet GOD, I hope no one ever has to
> Even cron'd scripts can run amok. Lock files are great as a CYA
> measure even if you're relatively certain there will be no opportunity
> for one copy to step on the next.
Yes, you are absolutely correct, of course. :)
I should be more specific - I'm working on a personal project, and I'm
no
> Gee, now I have images of late-night advertisements for bofh-porn video
> tapes
> of Cron Jobs Gone Wild(tm) dancing through my head... thanks.
Wow. THERE'S something I didn't need before hitting the sack. ;)
Benny
--
"Even if a man chops off your hand with a sword, you still have two nic
Hey folks,
I'm in the middle of a database design update, mostly to undo all of
the stupid things I did in version 0.01. :) God knows I made enough
of them...
I have a table with the following columns:
dns1_ptr | inet | default '0.0.0.0'::inet
dns2_ptr | inet
> How does dns_ptr relate to other data? Depending on what you're
> doing, other ways of organizing your tables might also make sense.
These are actually DNS servers authoritive for a domain that is stored
in a VARCHAR() in the same table.
After sleeping on it, I think using an array is indeed
Hey folks (long email, my apologies),
I am wrapping up my schema upgrade, and I just noticed a real
show-stopper for me... Here is the "before" table structure:
email_id | integer | not null
joejob| boolean | default false
bayes
> Foreign keys have zero, nada, zilch to do with the performance of
> count(*).
OK, I just wanted to make sure.
> The only plausible theory I can think of for the performance
> difference is that in your "new" database the table has been through
> several mass updates, leading to a whole lot of
Hey folks,
I am still slogging away on my pet project, and I'm giving up - I
need help from the experts to try to get this function working like
I want it to.
I have a very basic function, thanks to you guys a few months ago:
CREATE OR REPLACE FUNCTION public.next_bill_date(d date, perio
> http://www.postgresql.org/docs/8.4/interactive/plpgsql-control-structures.html#PLPGSQL-STATEMENTS-RETURNING
>
>CREATE OR REPLACE FUNCTION public.next_bill_date(d date, period
>interval,
> i interval)
> RETURNS SETOF date
> AS $function$
> DECLARE
> max_date date;
> due_date date;
> BE
10 matches
Mail list logo
