| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Joe Conway <mail(at)joeconway(dot)com>, Kris Jurka <books(at)ejurka(dot)com>, Alex <alex(at)meerkatsoft(dot)com>, "Lada 'Ray' Lostak" <ray(at)unreal64(dot)net>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question) |
| Date: | 2003-12-01 18:54:47 |
| Message-ID: | 25203.1070304887@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> There was just a discussion a few days ago about the page size for large
>> objects, for which the correct answer was "BLCKSZ/4" IIRC. Whether
>> people actually *should* care about the page size of large objects I
>> dunno, but the fact is some of them *do* care.
> Maybe we should provide specific functions to access this information, so
> client applications don't have to hardcode these formulas.
That's exactly what this thread is about: current_setting() is the
proposed access function ...
I'm not convinced that large object pagesize is interesting enough to
deserve its own GUC variable, but if someone wanted to make that case
I'm certainly open to listening.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Doug McNaught | 2003-12-01 18:57:40 | Re: disaster recovery |
| Previous Message | Peter Eisentraut | 2003-12-01 18:51:14 | Re: export FUNC_MAX_ARGS as a read-only GUC variable (was: |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2003-12-01 18:59:50 | Re: [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions? |
| Previous Message | Peter Eisentraut | 2003-12-01 18:51:14 | Re: export FUNC_MAX_ARGS as a read-only GUC variable (was: |