Le 15/10/2021 à 10:37, Aleksander Alekseev a écrit :
> Hi Gilles,
>
> > I can turn the column hidden and I will not have to modify my old
> very good application.
>
> I see your point. At the same time, I believe the statement above
> shows the root reason why we have a different view on this feature.
> The application should have never use SELECT * in the first place.
> This is a terrible design - you add a column or change their order and
> the application is broken. And I don't believe the DBMS core is the
> right place for placing hacks for applications like this. This should
> be solved in the application itself or in some sort of proxy server
> between the application and DBMS. SELECT * is intended to be used by
> people e.g. DBA.
Yes I understand this point. Personally I have always used PostgreSQL
and exclusively PostgreSQL in 25 years so I am aware of that and try to
give my best to SQL code quality. But we have more and more application
coming from others RDBMS with sometime no real possibility to modify the
code or which requires lot of work. To give an other use case, some time
ago I have written an extension (https://github.com/darold/pgtt-rsl)
which use a technical column based on a composite type based on the
backend start time and pid to emulate Global Temporary Table. To be able
to hide this column from the user query point of view, I had to create
a view and route any action on this view to the real underlying table in
the extension C code. If the hidden feature was implemented it would
have same me some time. I see several other possible extensions that
could benefit of this feature.
As I said when you develop an extension you can not just say to the user
to never used SELECT * if he want to use your extension. At least this
is something I will never said, even if this is a bad practice so I have
to find a solution to avoid showing technical columns. If we really want
SELECT * to be reserved to DBA then why not removing the star from PG
unless you have the admin privilege?
--
Gilles Darold