From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Publish autovacuum informations |
Date: | 2015-01-02 17:21:56 |
Message-ID: | 54A6D3B4.3090505@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/1/15, 4:17 PM, Noah Misch wrote:
>> I'd be all right with putting the data structure declarations in a file
>> >named something like autovacuum_private.h, especially if it carried an
>> >annotation that "if you depend on this, don't be surprised if we break
>> >your code in future".
> Such an annotation would be no more true than it is for the majority of header
> files. If including it makes you feel better, I don't object.
We need to be careful with that. Starting to segregate things into _private headers implies that stuff in non-private headers *is* locked down. We'd need to set clear expectations.
I do think more clarity would be good here. Right now the only distinction we have is things like SPI are spelled out in the docs. Other than that, the there really isn't anything to indicate how safe it is to rely on what's in the headers. For example, I've got some code that's looking at fcinfo->flinfo->fn_expr, and I have no idea how likely that is to get broken. Since it's a parse node, my guess is "likely", but I'm just guessing.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-01-02 17:24:58 | Re: Compression of full-page-writes |
Previous Message | Claudio Freire | 2015-01-02 17:18:12 | Re: Compression of full-page-writes |