Han Qi's questions

Fiquei surpreso select date_trunc('day','2021-02-16 20:00+04'::timestamptz);ao retornar 2021-02-17 00:00:00+08no postgres.

É como se tivéssemos avançado no tempo do dia 16 para o dia 17.

Quero verificar meu entendimento e encontrar fontes que expliquem isso (de preferência oficiais).

A sessão temset timezone = 'Asia/Singapore'; --utc+8

Meu entendimento

Há duas transformações acontecendo antes do truncamento:

1. 20:00+04 se transforma em 16:00+00 armazenado como um inteiro de 8 bits (tempo de época em microssegundos) que o postgres usa para representar instantes no tempo físico (em oposição ao tempo civil mencionado em https://errorprone.info/docs/time )
2. Quando date_truncexecutado, 16:00+00 se torna no dia seguinte 00:00+08 porque date_truncinterpreta no horário local (fuso horário da sessão)

Testei a hipótese alterando a entrada para 2021-02-16 20:00+05, que gera 2021-02-16 00:00:00+08. (sem incremento de dia).

Acho que isso ocorre porque a 1ª transformação retrocedeu mais 1 hora, para 15:00+00, então a 2ª transformação só chegou às 23:00 do dia 16, em vez de meia-noite do dia 17?

Não consegui encontrar nenhum documento mencionando esse comportamento de dupla interpretação. O mais próximo está abaixo:

Quando o valor de entrada é do tipo timestamp com fuso horário, o truncamento é executado com relação a um fuso horário específico; por exemplo, o truncamento para day produz um valor que é meia-noite naquele fuso horário. Por padrão, o truncamento é feito com relação à configuração TimeZone atual, mas o argumento opcional time_zone pode ser fornecido para especificar um fuso horário diferente.

https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-TRUNC

set timezone = 'Asia/Ho_Chi_Minh';

Defino os horários exibidos para GMT+7.

select '2021-02-16 09:00' AT TIME ZONE 'Asia/Singapore';
select '2021-02-16 09:00+06' AT TIME ZONE 'Asia/Singapore';

Saída

2021-02-16 10:00:00
2021-02-16 11:00:00

Como AT TIME ZONEconverte timestamp without time zonepara timestamp with time zonee vice-versa ( https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT ), e como ambas as saídas são timestamp without time zone(você pode ver que elas não têm a parte + - ou pg_typeofpara confirmar), deduzo que ambas as literais de string são interpretadas como timestamp with time zone.

Entendo que a segunda seleção tem a +06parte para indicar o fuso horário, o que faz sentido.

Pergunta :

Por que a primeira seleção, que não tem parte de fuso horário + ou -, é interpretada como timestamp with time zonea segunda seleção?

Eu sei que posso especificar o tipo com TIMESTAMP/TIMESTAMP WITH TIME ZONE ou converter com ::timestamp/::timestamptz, mas supondo que eu não faça nada disso, há alguma documentação descrevendo o que está acontecendo com o literal de string?

De docs https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-DATETIME-INPUT-TIME-STAMPS

TIMESTAMP '2004-10-19 10:23:54+02' é um timestamp com fuso horário

Pergunta: Por que select pg_typeof(TIMESTAMP '2004-10-19 10:23:54+02');dá timestamp without time zone? Esperando timestamp with time zonecomo os médicos dizem.

Versão do Postgres

SELECT version();mostra PostgreSQL 14.14 (Debian 14.14-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit

DROP TABLE IF EXISTS A;
CREATE TABLE a (id int);

CREATE or replace FUNCTION insert_and_return(int) 
    RETURNS int AS $$
    BEGIN
        INSERT INTO a VALUES ($1);
        RETURN $1;
    END;
$$ LANGUAGE plpgsql;

SELECT * FROM insert_and_return(10),A AS y;

O código acima tem efeitos colaterais de inserção de dados no SELECT por meio de uma função.

Esperado

Eu esperava insert_and_returninserir uma nova linha quando FROM insert_and_return(10),Aocorre uma junção cruzada, antes que o SELECT a veja e a retorne no resultado.

Real :

Conjunto de resultados em branco

Pergunta :

Por que não vejo os dados? Tenho que SELECIONAR novamente para vê-los.

Acho que os SELECTs estão sempre vendo 1 linha a menos do que há.

Espero entender a ordem dos eventos nos bastidores, se os dados já estão inseridos, mas de alguma forma ocultos do SELECT, ou se não foram inseridos no momento em que o SELECT é executado.

Perguntas relacionadas

• Essa pergunta tem algo a ver com níveis de isolamento ou é irrelevante porque os níveis de isolamento só se aplicam a múltiplas transações?

• Por que os dados podem ser gerados dinamicamente com CASE ou padrões semelhantes, SELECT price, price * 0.9mas isso não funciona aqui?

Tentei criar separação com CTE, mas vejo o mesmo comportamento em que só vejo dados ao executar a consulta inteira abaixo uma 2ª vez. Isso pode ser explicado pelos mesmos motivos acima, ou o CTE tem suas próprias ressalvas?

WITH inserted_data AS (
    INSERT INTO a (id) VALUES (10)
    RETURNING id
)
SELECT * FROM inserted_data,A;

Por que outra ajuda falhou

Todas as fontes que encontro online falam sobre leitura/gravação simultânea de múltiplas transações, o que acredito ser irrelevante porque se trata de uma única consulta em uma única transação implícita.

Origem da 1ª consulta

Eu o ajustei deste artigo que foca no balanceamento de carga em vez da minha pergunta: https://www.cybertec-postgresql.com/en/why-select-from-table-is-not-a-read , por favor, indique se minha pergunta é muito extrema para ser relevante na prática

Dentro dos pacotes do site, há pastas pyteste _pytest. A maior parte do código principal está em _pytest.

Ao olhar para pyproject.toml, não consegui descobrir como o setuptools sabe instalar pyteste _pytest.

Pensei que fosse devido à existência de __init__.pyarquivos, mas outras pastas testing/example_scriptstambém os têm, então é improvável.

Também não há um setup.py em https://github.dev/pytest-dev/pytest . Eu estava procurando por algo como:

setup(
    name='your_project_name',
    version='0.1',
    packages=find_packages()  # or something like ['pytest', '_pytest']
)

Além disso, por que mostra pip liste pipdeptreenão mostra _pytest?

Presumi que todos os pacotes em site-packages serão exibidos. Pensei que os pacotes que começam com _são privados, como as variáveis ​​privadas do Python, mas não há opções em pip listrelação à exibição de "pacotes privados".