Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
I have attached a little change to varlena.c that uses it. I left the
ereport as it was, but am not fussed about it either way.
I am, because it gives useless messages
Patch applied. Thanks.
---
Mark Kirkwood wrote:
> Alvaro Herrera wrote:
> > On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
> >
> >>Neil Conway wrote:
> >
> >
> >>>elog(ERROR) is usually used for "can't h
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> I did some tests with a two tables, one small and one large, I am seeing
> a consistent difference favoring the first-call-only type checking:
We had come to a similar conclusion in regards to making array-related
functions cache lookup info across calls
Neil Conway wrote:
Mark Kirkwood wrote:
I didn't performance test it, but the idea of hammering the catalogs for
each value to be processed seemed a bad thing.
Well, the syscache already sits in front of the catalogs themselves. I'd
be curious to see what the performance difference actually
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
>> I have attached a little change to varlena.c that uses it. I left the
>> ereport as it was, but am not fussed about it either way.
> I am, because it gives useless messages to the transla
Alvaro Herrera wrote:
On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
Neil Conway wrote:
elog(ERROR) is usually used for "can't happen" errors.
I have attached a little change to varlena.c that uses it. I left the
ereport as it was, but am not fussed about it either way.
On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
> Neil Conway wrote:
> >elog(ERROR) is usually used for "can't happen" errors; also, the usual
> >error message in this scenario is "cache lookup failed [...]". Perhaps
> >better to use get_typlen() here, anyway.
>
> I have attached
Mark Kirkwood wrote:
I didn't performance test it, but the idea of hammering the catalogs for
each value to be processed seemed a bad thing.
Well, the syscache already sits in front of the catalogs themselves. I'd
be curious to see what the performance difference actually is...
-Neil
--
Neil Conway wrote:
Bruce Momjian wrote:
+ /* + * Return the length of a datum, possibly compressed
+ */
+ Datum
+ pg_column_size(PG_FUNCTION_ARGS)
+ {
+ Datumvalue = PG_GETARG_DATUM(0);
+ intresult;
+ + /*fn_extra stores the fixed column length, or
Bruce Momjian wrote:
+ /*
+ * Return the length of a datum, possibly compressed
+ */
+ Datum
+ pg_column_size(PG_FUNCTION_ARGS)
+ {
+ Datum value = PG_GETARG_DATUM(0);
+ int result;
+
+ /* fn_extra stores the fixed column length, or -
Mark Kirkwood wrote:
> I did a few cleanups on the last patch. Please examine this one instead.
> The changes are:
>
> 1. Add documentation for pg_datum_length builtin.
> 2. Correct some typos in the code comments.
> 3. Move the code in toastfuncs.c to varlena.c as it is probably the
> correct pla
I did a few cleanups on the last patch. Please examine this one instead.
The changes are:
1. Add documentation for pg_datum_length builtin.
2. Correct some typos in the code comments.
3. Move the code in toastfuncs.c to varlena.c as it is probably the
correct place.
4. Use ereport instead of elog
The next iteration -
Hopefully I have got the idea basically right.
I wonder if I have done the "am I a varlena" the long way.., pls advise
if so!
Cheers
Mark
Tom Lane wrote:
My recollection of that discussion is that we just wanted something
that would return the actual VARSIZE() of the da
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
I thought I would have a look at:
(Datatypes) Add function to return compressed length of TOAST data values.
My recollection of that discussion is that we just wanted something
that would return the actual VARSIZE() of the datum. You
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> I thought I would have a look at:
> (Datatypes) Add function to return compressed length of TOAST data values.
My recollection of that discussion is that we just wanted something
that would return the actual VARSIZE() of the datum. You're building
somet
I thought I would have a look at:
(Datatypes) Add function to return compressed length of TOAST data values.
A WIP patch is attached for comment (wanted to check I hadn't bitten off
more than I could chew *before* asking questions!).
A few questions come to mind:
1) The name - I have called it
16 matches
Mail list logo
