Greetings,
* Dave Cramer (davecramer@gmail.com) wrote:
> On 8 August 2018 at 15:52, Rob Richardson <interrobang@yahoo.com> wrote:
> > I have now downloaded pgAdmin 4 v3.1. It has the same problem.
> > I run this command:
> >
> > CREATE TABLE public.identity_sample
> > (
> > identity_sample_key bigint NOT NULL GENERATED BY DEFAULT AS
> > IDENTITY PRIMARY KEY
> > )
> > WITH (
> > OIDS = FALSE
> > )
> >
> > Then, I run
> >
> > select attrelid, attname, attidentity from pg_attribute where attname
> > = 'identity_sample_key'
> >
> > and get two records, one of which has an attidentity column that contains
> > 'd'. The other record's attidentity column is null.
> >
> > Then, in pgAdmin, I refresh the schema and select the identity_sample
> > table. In the SQL tab, I see this:
> >
> > -- DROP TABLE public.identity_sample;
> > CREATE TABLE public.identity_sample
> > (
> > identity_sample_key bigint NOT NULL,
> > CONSTRAINT identity_sample_pkey PRIMARY KEY (identity_sample_key)
> > )
> > WITH (
> > OIDS = FALSE
> > )
> > TABLESPACE pg_default;
> >
> > I copy that into a new SQL window, uncomment the DROP TABLE line, and
> > execute it. Then, I repeat the select query on pg_attribute. Again, I get
> > two records, but this time the attidentity column is null for both records.
> that seems like a bug, at least a feature that should be there..
Yeah, I tend to agree.. Seems like pgAdmin4 really should be realizing
that it's an identity column and creating a CREATE TABLE statement as
such, though it'll need code specific to v10 and above to do that.
I'm not at all surprised that pgAdmin3 has this issue and I wouldn't get
your hopes up about seeing that fixed. This should get fixed for
pgAdmin4 though.
Thanks!
Stephen