Greetings, * Dave Cramer (davecra...@gmail.com) wrote: > On 8 August 2018 at 15:52, Rob Richardson <interrob...@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
signature.asc
Description: PGP signature
