* Josh Berkus (j...@berkus.org) wrote:
> On 02/09/2017 05:19 PM, Michael Paquier wrote:
> > On Fri, Feb 10, 2017 at 10:16 AM, Stephen Frost <sfr...@snowman.net> wrote:
> >>> As someone mentioned, forcing a user to install an extension makes
> >>> the deprecation visible. Another option would be to have the backend
> >>> spit out a WARNING the first time you access anything that's
> >>> deprecated. Both of those are pertinent reminders to people that
> >>> they need to change their tools.
> >>
> >> Ugh.  Please, no.  Hacking up the backend to recognize that a given
> >> query is referring to a deprecated view and then throwing a warning on
> >> it is just plain ugly.
> >>
> >> Let's go one step further, and throw an ERROR if someone tries to query
> >> these views instead.
> > 
> > FWIW, I am of the opinion to just nuke them as the "soft of"
> > deprecation period has been very long. Applications should have
> > switched to pg_authid and pg_roles long ago already.
> We will definitely break a lot of client code by removing these -- I
> know that, deprecated or not, a lot of infrequently-updated
> driver/orm/GUI code still refers to pg_shadow/pg_user.

Any that we're aware of, I'd suggest we reach out to the maintainers of
and let them know.

> I think Postgres 10 is the right time to break that code (I mean, we
> have to do it someday, and we're already telling people about breakage
> in 10), but be aware that there will be shouting and carrying on.


> -1 on a warning.  Very little code today which references the deprecated
> code is interactive, so who's going to see the warning?

Indeed, I was thinking of this also.  The warnings would just end up in
the server logs, amongst tons of often not-terribly-interesting
information that far too many users ignore already, and those that don't
probably actually read the release notes.



Attachment: signature.asc
Description: Digital signature

Reply via email to