From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Naylor <jcnaylor(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, David Fetter <david(at)fetter(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: a way forward on bootstrap data |
Date: | 2018-01-14 16:44:30 |
Message-ID: | 15339.1515948270@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Another thing that I'd sort of hoped might happen from this patchset
> is to cure the problem of keeping some catalog headers safe for
> client-side inclusion, because some clients want the OID value macros
> and/or macros for column values (eg PROVOLATILE_IMMUTABLE), so they
> currently have to #include those headers or else hard-code the values.
> We've worked around that to date with ad-hoc solutions like splitting
> function declarations out to pg_*_fn.h files, but I never liked that
> much. With the OID value macros being moved out to separate generated
> file(s), there's now a possibility that we could fix this once and for all
> by making client-side code include those file(s) not pg_type.h et al
> themselves. But we'd need a way to put the column-value macros into
> those files too; maybe that's too messy to make it practical.
I had a thought about how to do that. It's clearly desirable that that
sort of material remain in the manually-maintained pg_*.h files, because
that's basically where you look to find out C-level details of what's
in a particular catalog. However, that doesn't mean that that's where
the compiler has to find it. Imagine that we write such sections of the
catalog .h files like
#ifdef EXPOSE_TO_CLIENT_CODE
/*
* ... comment here ...
*/
#define PROVOLATILE_IMMUTABLE 'i' /* never changes for given input */
#define PROVOLATILE_STABLE 's' /* does not change within a scan */
#define PROVOLATILE_VOLATILE 'v' /* can change even within a scan */
#endif /* EXPOSE_TO_CLIENT_CODE */
Like CATALOG_VARLEN, the symbol EXPOSE_TO_CLIENT_CODE is never actually
defined to the compiler. What it does is to instruct genbki.pl to copy
the material up to the matching #endif into the generated file for this
catalog. So, for each catalog header pg_foo.h, there would be a
generated file, say pg_foo_d.h, containing:
* Natts_ and Anum_ macros for pg_foo
* Any EXPOSE_TO_CLIENT_CODE sections copied from pg_foo.h
* Any OID-value macros for entries in that catalog
pg_foo.h would contain a #include for pg_foo_d.h, so that backend-side
code would obtain all these values the same as it did before. But the
new policy for client code would be to include pg_foo_d.h *not* pg_foo.h,
and so we are freed of any worry about whether pg_foo.h has to be clean
for clients to include. We could re-merge the various pg_foo_fn.h files
back into the main files, if we wanted.
The contents of EXPOSE_TO_CLIENT_CODE sections wouldn't necessarily
have to be just macros --- they could be anything that's safe and
useful for client code. But that's probably the main usage.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2018-01-14 17:55:26 | Re: WIP: a way forward on bootstrap data |
Previous Message | Tom Lane | 2018-01-14 15:45:25 | Re: WIP: a way forward on bootstrap data |