Para responder a essa pergunta, fiz o seguinte (todo o código abaixo está disponível no violino aqui ):

CREATE SEQUENCE user_id_seq;
CREATE SEQUENCE address_id_seq;

e as tabelas:

CREATE TABLE user_
(
    id integer NOT NULL DEFAULT nextval('user_id_seq'::regclass),
    email character varying COLLATE pg_catalog."default" NOT NULL,
    CONSTRAINT "PK_cace4a159ff9f2512dd42373760" PRIMARY KEY (id),
    CONSTRAINT "UQ_e12875dfb3b1d92d7d7c5377e22" UNIQUE (email)
);

e

CREATE TABLE address
(
    id integer NOT NULL DEFAULT nextval('address_id_seq'::regclass),
    address character varying COLLATE pg_catalog."default" NOT NULL,
    user_id integer,
    CONSTRAINT "PK_bec464dd8d54c39c54fd32e2334" PRIMARY KEY (id),
    CONSTRAINT "FK_35472b1fe48b6330cd349709564" FOREIGN KEY (user_id)
        REFERENCES user_ (id) MATCH SIMPLE
        ON UPDATE NO ACTION
        ON DELETE NO ACTION
);

Usamos a RETURNINGcláusula do PostgreSQL com uma expressão de tabela comum (CTE - também conhecida como WTIHcláusula).

Um exemplo simples:

WITH insert_user AS
(
  INSERT INTO user_ (email) VALUES ('[email protected]')
  RETURNING id
)
SELECT *  FROM insert_user;

Resultado:

id  email
1   [email protected]

Assim, podemos ver que podemos obter o id da INSERTinstrução dentro do CTE.

Agora, vamos dar um passo adiante da seguinte forma:

BEGIN TRANSACTION;
WITH insert_user AS
(
  INSERT INTO user_ (email) VALUES ('[email protected]')
  RETURNING id
)
INSERT INTO address (address, user_id)
SELECT '1, Long Street, Somewhere', (SELECT id FROM insert_user)
COMMIT;

Usamos uma transação - apenas no caso de haver um problema na etapa da primeira INSERTpara a segunda.

SELECT * FROM user_;
and
SELECT * FROM address;

Resultados:

id  email
2   [email protected]
and
id         address            user_id
1   1, Long Street, Somewhere       2

Vemos que o user_idde 2 está na addresstabela - tendo vindo do INSERTpara dentro da user_tabela no CTE.

Você tem INSERT um valor para emailo usuário por causa da NOT NULLrestrição na user_definição da tabela! Você pode remover a restrição, mas vejo pouco sentido nisso.

Alguns pontos a serem observados:

• você usa CHARACTER VARYING- o tipo de dados do PostgreSQL TEXTé mais adequado para isso .

• COLLATE pg_catalog."default"é redundante - se não for especificado, o agrupamento será o padrão.

• você usa identificadores entre aspas, ou seja - muito melhor usar a convenção de nomenclatura recomendada"userId" do PostgreSQL e transformar isso em - ou seja, snake_case!user_id

• você tem os nomes mais bizarros para restrições que eu já vi!

  CONSTRAINT "PK_bec464dd8d54c39c54fd32e2334" PRIMARY KEY (id),

  e

  CONSTRAINT "FK_35472b1fe48b6330cd349709564" FOREIGN KEY ("userId")... REFERENCES...

  A única razão para isso é que foi tirado de algum outro sistema que dá esses nomes horríveis. Muito melhor ter address_pk_idou algo semelhante (ou seja, significativo). Uma mensagem de erro informando que a restrição "PK_bec464dd8d54c39c54fd32e2334" foi violada não vai dizer muito a ninguém! Além disso, transmitir isso por telefone será difícil - muito melhor usar um nome simples com o qual os usuários possam se relacionar.

Para responder as perguntas:

1ª pergunta:

• Can I generate the user ID from the sequence in some other way than entering an email in to the table and in the end enter both the ID and the email at the same time?

Você poderia fazer o seguinte:

SELECT nextval('user_id_seq');

Resultado:

nextval
      3

e, em seguida, INSERTna tabela de endereços junto com um endereço. Mas, qual é o ponto? Você precisa ter alguma maneira de relacionar um determinado usuário a um determinado endereço - e você faz isso agrupando seu SEQUENCEvalor em uma transação - primeiro INSERTna user_tabela e depois usando esse valor da RETURNINGcláusula para criar o endereço.

2ª pergunta:

• Can I save the address in the addresses table referencing a foreign key which has not yet been added to users?

Não! O ponto principal de FOREIGN KEYs é que você não pode inserir nada na tabela de endereços que não tenha um user_idretorno válido no idcampo da user_tabela.

Você poderia largar as restrições e ter alguma bagunça processual medonha para acompanhar o que foi e o que não foi INSERTeditado onde e quando - mas novamente, por quê? Seu banco de dados fará todo o trabalho de acompanhar tudo isso se você permitir!