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;
BEGIN
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,
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 nice,
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
not
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 read
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
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
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 dead
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,
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
10 matches
Mail list logo
