Postgres Pro
Downloads
Home   >   mailing lists

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead - Mailing list pgsql-hackers

From Nikolay Shaplov
Subject Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead
Date
Msg-id 2005730.TFoJP5CCPs@x200m
Whole thread Raw
In response to Re: [PATCH] get rid of StdRdOptions, use individual binaryreloptions representation for each relation kind instead  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [PATCH] get rid of StdRdOptions, use individual binaryreloptions representation for each relation kind instead  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Tree view 
В письме от четверг, 3 января 2019 г. 16:10:20 MSK пользователь Alvaro Herrera
написал:
> On 2019-Jan-02, Nikolay Shaplov wrote:
> > This is internal API, right? If we change it everywhere, then it is
> > changed and nothing will be broken?
>
> No, it's exported for extensions to use.  If we change it unnecessarily,
> extension authors will hate me (not you) for breaking the compile and
> requiring an #if VERSION patch.

Ok, that's a good reason...

Can we think about backward compatibility aliases?

#define ViewHasCheckOption(relation)                       \
     ((relation)->rd_options &&                        \
         ((ViewOptions *) (relation)->rd_options)->check_option_offset != 0)

/* Alias for backward compatibility */
#define RelationHasCheckOption(relation) ViewHasCheckOption(relation)

And keep them for as log as needed to avoid #if VERSION in thirdparty code?

Or that is not the case?

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] get rid of StdRdOptions, use individual binaryreloptions representation for each relation kind instead
Next
From: Paul Ramsey
Date:
Subject: Re: Changing SQL Inlining Behaviour (or...?)