fix #6198: stop considering generated column definition as being its default value #6199
Conversation
|
I've tested manually on Postgresql 10 (with no support at all of GENERATED column, hence the feature detection code ) , Postgresql 13, 14, 15 For automated test, I've written one, but to be honest I haven't found a documentation on how to run them |
|
Ok I've finally been able to setup the CI locally for postgresql and correct the coding style so now I'm pretty sure all will be green :) |
|
@derrabus I see there's still some changes requested in this PR, but normally I've adressed everything ? Is there's something you're waiting from me ? (I don't mean to push you, if it's just a "I didn't have time yet to check it" , no worry I'll way 😊 , it's just I'm suddenly thinking "maybe he's the one waiting for me" ^^" ) |
|
No, I'm aware that the ball's in my court here. 😓 |
allan-simon
force-pushed
the
fix_6198
branch
2 times, most recently
from
361a954
to
b4d9b2f
Compare
|
repushed (I forgot to run phpcs locally) and squashed, the previous CI was only failing on IBM DB2 test, but it seems to me it was a flaky test |
allan-simon
force-pushed
the
fix_6198
branch
from
b4d9b2f
to
bfb754f
Compare
|
@derrabus the fail seems to be a flaky test , can you relaunch them ? |
allan-simon
force-pushed
the
fix_6198
branch
from
bfb754f
to
96cd2b6
Compare
…ing its default value The `pg_get_expr(adbin, adrelid)` expression in Postgresql's internal table `pg_attrdef` is used to know a column definition for most column, if this returns something, it means this column's default value. So DBAL has been considering has ALWAYS meaning it contains its default. However for generated columns, it contains the value definition and not its default value, so we change the selectTableColumns' query to correctly set the 'default' column to `null` for generated columns It will help setting correctly the column's attributes which in turn will help generate correct schema diff.
Is this sentence broken? I don't understand it. |
yes , sorry I meant DBAL was interpreting "pg_get_expr(adbin, adrelid) returns something" as meaning "the value returned is the default value of the column " while it's a more generic "definition value" which can be the default value , but can also be other things (like the generated column expression ) I think the confusion was that postgresql uses the abbreviated form "pg_attrdef" and one could have interpreted that as "postgresql attribute default" whereas it actually means "postgresql attribute definition" |
Summary
The
pg_get_expr(adbin, adrelid)expression in Postgresql's internal tablepg_attrdefis used to know a column definitionfor most column, if this returns something, it means this column's default value. So DBAL has been considering has ALWAYS meaning it contains its default.
However for generated columns, it contains the value definition and not its default value, so we change the selectTableColumns' query to correctly set the 'default' column to
nullfor generated columnsIt will help setting correctly the column's attributes which in turn will help generate correct schema diff.