| From: | Dave Page <dpage(at)pgadmin(dot)org> |
|---|---|
| To: | Melvin Davidson <melvin6925(at)yahoo(dot)com> |
| Cc: | ldrlj1 <russelljanusz(at)masterpeaceltd(dot)com>, pgAdmin Support <pgadmin-support(at)postgresql(dot)org> |
| Subject: | Re: PGAdmin Version 2.1 |
| Date: | 2018-01-30 15:27:55 |
| Message-ID: | CA+OCxowRk6=uz2D7FnP4X-eZxs5FfGdkFu2CNjYrYiaDLrSw=A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgadmin-support |
On Tue, Jan 30, 2018 at 3:22 PM, Melvin Davidson <melvin6925(at)yahoo(dot)com>
wrote:
> *>No - if you switch on "Show system objects", it will display system
> objects such as row *
> *>types. That's the whole point of the switch (which is off by default). *
>
> *Except that "system objects" are NOT USER tables, views, indexes, etc.*
>
> *They are _system_ catalogs and views;*
>
Not in nearly 20 years of pgAdmin history they haven't been. We've always
classed them as system catalogs etc. *and* objects that are implementation
details of higher level objects.
>
> *Your definition is a behavior change from PgAdmin III, which DID NOT show
> *
> *every "system object" per your definition". It only showed USER types as
> per*
> *my query.*
>
No it didn't. See the attached screenshot.
Why would you force objects like these to be permanently hidden? It's quite
reasonable to want to see them - they can be quite useful when writing
stored procedures that deal with rows for example.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| Attachment | Content-Type | Size |
|---|---|---|
|
image/png | 35.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Raymond O'Donnell | 2018-01-30 18:31:32 | Re: pgAdmin4 from apt.postgresql.org |
| Previous Message | Melvin Davidson | 2018-01-30 15:22:22 | Re: PGAdmin Version 2.1 |