On Mon, Jul 8, 2013 at 2:18 PM, Andreas wrote:
> How could I combine those 2 queries so that the date in query 1 would be
> replaced dynamically with the result of the series?
>
Surely I'm missing something, but maybe this is something to work on:
WITH
RECURSIVE months(number) AS ( SELECT 1 UN
Hi,
yeah, I am okay with design prudence, just used to be so paranoid about
performance that just any possible "one more thing to do" gets me nervous
:) Language versions do exist, say Dutch has different orthography
depending on what convention is used, so you may well need to suddenly add
a furt
On Wed, Jul 24, 2013 at 11:47 AM, Bèrto ëd Sèra wrote:
> Hi,
>
> It looks heavy, performance-wise. If this is not OLTP intensive you can
> probably survive, but I'd still really be interested to know ow you can end
> up having non unique records on a Cartesian product, where the PK is defined
> by
On Wed, Jul 17, 2013 at 5:29 PM, Carla Goncalves wrote:
> Hi
> I would like to list the definition of all user tables by only one command.
> Is there a way to *not* show pg_catalog tables when using "\d ." in
> PostgreSQL 9.1.9?
>
What do you mean by "user tables"? The execution of \d without any
Hi,
It looks heavy, performance-wise. If this is not OLTP intensive you can
probably survive, but I'd still really be interested to know ow you can end
up having non unique records on a Cartesian product, where the PK is
defined by crossing the two defining tables. Unless you take your PK down
the
On Wed, Jul 24, 2013 at 10:38 AM, Bèrto ëd Sèra wrote:
> What would be the rationale behind the serial number?
>
The serial key, also named "surrogate key" is there for management
purposes. Imagine one day you find out your database design is wrong
and what was unique the day before is no more s
Hi,
> I also need the field "lpp_id" as a unique key which is a field that
contains a consecutive number of type serial.
Are you sure you REALLY need this? It looks like a lot of trouble for
nothing, as you now have one thing warranting the unicity of the record
(your serial) plus a unique key wa
Agreed with Anton, as PK, lpp_id is easier to be managed than (lpp_person_id
+ lpp_language_id)
One more suggestion, foreign key constraints could be setup on lpp_person_id
and lpp_language_id to link with target tables.
Thanks,
Stan
2013/7/24 Anton Gavazuk
> The reason is simple - as you nee
The reason is simple - as you need the artificial PK lpp_id, then
everything else becomes an constraint
Thanks,
Anton
On Jul 24, 2013, at 0:28, JORGE MALDONADO wrote:
>> In your case it would be lpp_id as PK, and
>> lpp_person_id,lpp_language_id as unique constraint
>>
>> Thanks,
>> Anton
Is
