From: | Gaetano Mendola <mendola(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_tables bug? |
Date: | 2015-12-18 22:55:26 |
Message-ID: | CAJycT5q8b7=Gr3kjKMNRUCXT+27gjAz6f6ezWspPpSSNj1ACZw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 17 Dec 2015 at 15:36 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Gaetano Mendola <mendola(at)gmail(dot)com> writes:
> > I'm playing around with tablespace (postgresq 9.4) and I found out what I
> > believe is a bug in pg_tables.
> > Basically if you create a database in a table space X and then you
> create a
> > table on the database the table is created correctly on the tablespace X
> (
> > I did a check on the filesystem) however if you do a select on pg_tables
> > the column tablespace for that table is empty and even worst if you dump
> > the DB there is no reporting about the the database or table being on
> that
> > tablespace.
> > Even \d doesn't report that the table is in the tablespace X.
>
> An empty entry in that column means that the table is in the default
> tablespace for the database. Which it sounds like is what you have
> here. I think it's operating as designed, though you might quibble
> with the decision that showing default tablespaces explicitly would
> have been clutter.
>
Now it's clear thank you.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-12-18 23:07:48 | Re: [sqlsmith] Failing assertions in spgtextproc.c |
Previous Message | Gaetano Mendola | 2015-12-18 22:18:44 | Re: pg_tables bug? |