Re: Fixing contrib/isn for float8-pass-by-value - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing contrib/isn for float8-pass-by-value
Date
Msg-id 29870.1227902572@sss.pgh.pa.us
Whole thread Raw
In response to Fixing contrib/isn for float8-pass-by-value  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixing contrib/isn for float8-pass-by-value  (Greg Stark <greg.stark@enterprisedb.com>)
Re: Fixing contrib/isn for float8-pass-by-value  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
I wrote:
> The problem reported by Rushabh Lathia boils down to the fact that
> contrib/isn intends to define a datatype that is represented "just like
> int8", but it supposes that int8 must be pass by reference.  There is
> not anything wrong with the C code; the problem is the CREATE TYPE
> command in isn.sql.  To fix this we need some way of passing the state
> of FLOAT8PASSBYVAL into that SQL script.
> ...
> This is kinda ugly but I don't really see anything better.

I had a better but more invasive idea: invent a new attribute for
CREATE TYPE
LIKE   =  typename

which means "copy any unspecified representational details from the
given pre-existing type".  This would allow the .sql file to know
less instead of more about what's happening, so it seems more
future-proof.  It's a bit more work than the makefile hack I was
thinking about, but seems like a good investment.  (I wouldn't
propose this if I thought contrib/isn was the only user --- I expect
there are other third-party modules with similar needs.)

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "could not devise a query plan for the given query"
Next
From: "Greg Sabino Mullane"
Date:
Subject: Statement-level triggers and inheritance