Обсуждение: help defining a basic type operator

Hi all,
I'm trying to define a custom data type that would represent a number
of bytes in a lossy human way.
The type is defined as:

typedef struct HFSize
{
        double          size;
        int       scaling;
} HFSize;

and the operator function is defined as:

Datum
hfsize_add(PG_FUNCTION_ARGS)
{

  HFSize *first  = (HFSize *) PG_GETARG_POINTER(0);
  HFSize *second = (HFSize *) PG_GETARG_POINTER(1);
  HFSize *sum    = new_HFSize();

  to_bytes( first );
  to_bytes( second );

  elog( DEBUG1, "sum %s + %s ", to_string( first ), to_string( second ) );
  sum->size = first->size + second->size;

  elog( DEBUG1, "Final sum %s ", to_string( sum ) );
        PG_RETURN_POINTER( sum );
}



The problem is that, even if the last elog shows a correct result, the
final value returned via PG_RETURN_POINTER is something totally
different with the double value set to zero and an apparently random
'scaling':

# set client_min_messages to debug;
SET
testdb=# SELECT '1030'::hfsize + '2030'::hfsize;
DEBUG:  Converting to human text format 1030.00-bytes
LINE 1: SELECT '1030'::hfsize + '2030'::hfsize;
               ^
DEBUG:  Converting to human text format 2030.00-bytes
LINE 1: SELECT '1030'::hfsize + '2030'::hfsize;
                                ^
DEBUG:  sum 1030.00-bytes + 2030.00-bytes
DEBUG:  Final sum 3060.00-bytes
 ?column?
----------
 0.00-64


I've tried also to return one of the two operands from the add
function, so something like:
Datum
hfsize_add(PG_FUNCTION_ARGS)
{

  HFSize *first  = (HFSize *) PG_GETARG_POINTER(0);
  HFSize *second = (HFSize *) PG_GETARG_POINTER(1);
  PG_RETURN_POINTER( first );
}

but again the result has a zero value and a random scaling, and most
notably is not the first operand. Also memory addresses (used with %x)
are different from inside and outside the add function.
Is there something I'm missing?

Thanks,
Luca

Luca Ferrari <fluca1978@gmail.com> writes:
> I'm trying to define a custom data type that would represent a number
> of bytes in a lossy human way.

You did not show us the SQL definition of the type.  I don't see anything
obviously wrong in what you showed (other than hfsize_add not setting the
result's scaling), so the problem is somewhere else.  Given this C
declaration, the type probably needs to be size 16, double alignment,
pass-by-reference; maybe you messed up part of that?

>   HFSize *sum    = new_HFSize();

What is new_HFSize?

            regards, tom lane

On Mon, Aug 20, 2018 at 4:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Luca Ferrari <fluca1978@gmail.com> writes:
> > I'm trying to define a custom data type that would represent a number
> > of bytes in a lossy human way.
>
> You did not show us the SQL definition of the type.  I don't see anything
> obviously wrong in what you showed (other than hfsize_add not setting the
> result's scaling), so the problem is somewhere else.  Given this C
> declaration, the type probably needs to be size 16, double alignment,
> pass-by-reference; maybe you messed up part of that?
>

Shame on me: when I issued a create type I didn't realize that I was
miswriting the length attribute from 'internallength' to
'internalsize', and while an error was reported, the type was created.
Fixing the type creation into:

CREATE TYPE hfsize (
       internallength = 16,
       input  = hfsize_input_function,
       output = hfsize_output_function
);

solved the problem, so it was a length mismatch.

> >   HFSize *sum    = new_HFSize();
>
> What is new_HFSize?

An helper function to allocate a new object (and that was why scaling
did not get referenced in the add function):


HFSize*
new_HFSize()
{
  HFSize *size = (HFSize*) palloc( sizeof( HFSize ) );
  size->scaling = 0;
  size->size = 0.0f;
  return size;
}


Thanks,
Luca

Luca Ferrari <fluca1978@gmail.com> writes:
> Fixing the type creation into:

> CREATE TYPE hfsize (
>        internallength = 16,
>        input  = hfsize_input_function,
>        output = hfsize_output_function
> );

> solved the problem, so it was a length mismatch.

You really need to specify double alignment too; IIRC the default
assumption is only "int" alignment.  Intel processors will usually let you
get away with being sloppy about that, but it's still wrong (and there
*are* cases where Intel will complain too).

            regards, tom lane