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

From Alvaro Herrera
Subject Re: [PATCH] get rid of StdRdOptions, use individual binaryreloptions representation for each relation kind instead
Date
Msg-id 201901032015.aoeyqop5efom@alvherre.pgsql
Whole thread Raw
In response to Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead  (Nikolay Shaplov <dhyan@nataraj.su>)
Responses Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead  (Nikolay Shaplov <dhyan@nataraj.su>)
List pgsql-hackers
On 2019-Jan-03, Nikolay Shaplov wrote:

> 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?

Well, if you do this, at some point you need to tell the extension
author to change the code.  Or they can just keep the code unchanged
forever.  I don't think it's worth the bother.

I would have liked to get a StaticAssert in the definition, but I don't
think it's possible.  A standard Assert() should be possible, though.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Paul Ramsey
Date:
Subject: Re: Changing SQL Inlining Behaviour (or...?)
Next
From: Tom Lane
Date:
Subject: Re: Unified logging system for command-line programs