Marcos Pegoraro writes:
> Why is this important ? Well, if that file has a 2014-2025, I can know how
> old it is, more or less which version was included, etc
> Additionally, I see all of you adding or removing a single letter to
> sources, why not adjust those years on header files ?
Our git his
Em ter., 21 de jan. de 2025 às 14:50, Álvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> I have to ask, why do you think this is important?
>
I'm just reading sources, navigating on files history and learning, so
don't be furious with me.
Why is this important ? Well, if that file has a 2014-2
On 2025-Jan-21, Marcos Pegoraro wrote:
> But these numbers seem inaccurate, because there are 1644 copyright strings
> but 1521 are 1996-2025. So, JSONB, BRIN, FDW, Logical Replication and lots
> of others, all of them were started in 1996 or have any related code ?
I have to ask, why do you thin
Marcos Pegoraro writes:
> But these numbers seem inaccurate, because there are 1644 copyright strings
> but 1521 are 1996-2025.
[ shrug... ] I did not claim that this idea has been adhered to 100%.
In a code base as old and large as ours, very few things are adhered
to 100%.
Em ter., 21 de jan. de 2025 às 12:36, Tom Lane escreveu:
> so we prefer to use the same copyright dates as related older files even
> in less
> clear-cut cases.
>
Thank you Tom for your time.
But these numbers seem inaccurate, because there are 1644 copyright strings
but 1521 are 1996-2025. So,
Marcos Pegoraro writes:
> Today Amit Langote committed execScan.h and put on its header years from
> 1996 to 2025. Those years are what exactly ?
1996 is when the open-source Postgres effort started.
There's a bigger philosophical issue here, which is whether a new file
shouldn't just list the c
Today Amit Langote committed execScan.h and put on its header years from
1996 to 2025. Those years are what exactly ?
This file has 1996, but sometimes is the first commit year of that file,
sometimes is completely unrelated. What is right for it ? Need that to be
adjusted ?
/*
