Can I insert in a programmatically defined PostgreSQL table using SQL language?

Context: I'm trying to INSERT data in a partitioned table. My table is partitioned by months, because I have lots of data (and a volume expected to increase) and the most recent data is more often queried. Any comment on the partition choice is welcome (but an answer to my question would be more than welcome).

The documentation has a partition example in which, when inserting a line, a trigger is called that checks the new data date and insert it accordingly in the right "chil开发者_开发技巧d" table. It uses a sequence of IF and ELSIF statements, one for each month. The guy (or gal) maintaining this has to create a new table and update the trigger function every month.

I don't really like this solution. I want to code something that will work perfectly and that I won't need to update every now and then and that will outlive me and my grand-grand-children.

So I was wondering if I could make a trigger that would look like this:

INSERT INTO get_the_appropriate_table_name(NEW.date) VALUES (NEW.*);

Unfortunately all my attempts have failed. I tried using "regclass" stuffs but with no success.

In short, I want to make up a string and use it as a table name. Is that possible?

I was just about to write a trigger function using EXECUTE to insert into a table according to the date_parts of now(), or create it first if it should not exist .. when I found that somebody had already done that for us - right under the chapter of the docs you are referring to yourself:
http://www.postgresql.org/docs/9.0/interactive/ddl-partitioning.html

Scroll all the way down to user "User Comments". Laban Mwangi posted an example.

Update:

The /interactive branch of the Postgres manual has since been removed, links are redirected. So the comment I was referring to is gone. Look to these later, closely related answers for detailed instructions:

• INSERT with dynamic table name in trigger function
• Table name as a PostgreSQL function parameter

For partitioning, there are better solutions by now, like range partitioning in Postgres 10 or later. Example:

• Better database for “keep always the 5 latest entries per ID and delete older”?