On Sun, May 31, 2015, at 01:16 PM, Francisco Olarte wrote:
>
> It may seem, and be, unideal from a redundancy perspective, but keys
> are more natural. It means you have user (Glen), folder (Glen, PGlist)
> and message (Glen,PGlist,27), different from (Glen,Inbox,27) or (Glen,
> PgList,28) or (
On Sun, May 31, 2015, at 12:53 AM, Tom Lane wrote:
> "Glen M. Witherington" writes:
> > And here's the query I want to do, efficiently:
>
> > SELECT * FROM c
> > JOIN b ON b.id = c.b_id
> > JOIN a ON a.id = b.a_id
> > WHERE a.id = 3
On Sat, May 30, 2015, at 11:33 PM, David G. Johnston wrote:
> This is one problem with using made up surrogate keys...
>
> The PK of A is a component of both the PK of B and the PK of C but you throw
> that information away by using serial fields for PKs instead. You should
> have unique ind
Sorry about the horrendous subject, let me explain by example:
Let's take this schema:
```
CREATE TABLE a (
id bigserial PRIMARY KEY,
created_at timestamp with time zone NOT NULL DEFAULT NOW()
);
CREATE TABLE b(
id bigserial PRIMARY KEY,
a_id bigint NOT NULL REFERENCES a(id),
create
