Just a question on this, Jan. Would one expect UNIONS for this sort of work?
I just did this which is useful anyway:
schematest=> SELECT (select count(id) from b.messages) + (select count(id) from a.messages);
?column? ----------
5
(1 row)
I see the horizons expanding! Common data (I often have an 'info' table) can be shared between schemas. I think my search_patch might go:
You can mix those in queries however you want. They are just namespaces with some additional security (even if you grant public access to an object inside a schema, one still needs access to the schema itself). The search path let's you hide one schemas objects behind another ones by chosing the order. You can use qualified or unqualified names and different search path's where one or the other makes sense in your application- and data-design. After all, all the objects reside in the same database and all access is covered by the same transaction.
The problem with expanded horizons is that one has more possibilities to screw it up at the same time he get's more flexibility. Well used, this is a powerfull feature. Poorly applied and inconsistently used it can become a maintenance nightmare.
Jan
this_schema, info_schema, public_schema
Thanks very much for the information.
Kind regards, Rory
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
