On Mon, May 5, 2014 at 6:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, May 5, 2014 at 3:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> And the controlled shared segment is likely to be how big exactly? It's >>> probably not even possible for it to be smaller than a page size, 4K or >>> so depending on the OS. I agree with Andres that a name would be a good >>> idea; complaining about the space needed to hold it is penny-wise and >>> pound-foolish. >> ... >> Now, all that having been said, I recognize that human-readable names >> are a generally useful thing, so I'm not going to hold my breath until >> I turn blue if other people really want this, and it may turn out to >> be useful someday. But if anyone is curious whether I'm *confident* >> that it will be useful someday: at this point, no. > > I'm not confident that it'll be useful either. But I am confident that > if we don't put it in now, and decide we want it later, there will be > complaints when we change the API. Better to have an ignored parameter > than no parameter.
I'm generally skeptical of that philosophy. If we put in an ignored parameter, people may pass pointers to NULL or to garbage or to an overly-long string, and they won't know it's broken until we make it do something; at which point their code will begin to fail without warning. Speaking as an employee of a company that maintains several PostgreSQL extensions that sometimes need to be updated for newer server versions, I'd rather have a clean API break that makes the build fail than a "soft" break that supposedly lets things continue working but maybe breaks them in subtler ways. Another problem with this idea is that we might never get around to making it do anything, and then the dead parameter is just a stupid and unnecessary wart. If we're going to do anything at all here for 9.4, I recommend ignoring the fact we're in feature freeze and going whole hog: add the name, add the monitoring view, and add the monitoring view for the main shared memory segment just for good measure. That way, if we get the design wrong or something, we have a chance of getting some feedback. If we're not going to do that, then I vote for doing nothing and considering later whether to break it for 9.5, by which time we may have some evidence as to whether and how this code is really being used. Anyone who expects PostgreSQL's C API to be completely stable is going to be regularly disappointed, as most recently demonstrated by the Enormous Header Churn of the 9.3 era. I don't particularly mind being the cause of further disappointment; as long as the breakage is obvious rather than subtle, the fix usually takes about 10 minutes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
