| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Nikolay Shaplov <dhyan(at)nataraj(dot)su> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
| Subject: | Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead |
| Date: | 2019-01-03 20:15:08 |
| Message-ID: | 201901032015.aoeyqop5efom@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2019-01-03 20:27:33 | BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name |
| Previous Message | Paul Ramsey | 2019-01-03 19:59:39 | Re: Changing SQL Inlining Behaviour (or...?) |