On Mon, Jul 02, 2007 at 10:44:55AM -0700, Eric wrote:
> I guess you can also get this before writing code from
>
> select typbyval from pg_type where typname='mytype'
Note that the flag might not be constant. For example int8 is not byval
currently whereas it could be on a 64-bit architecture. Ho
I guess you can also get this before writing code from
select typbyval from pg_type where typname='mytype'
...thanks again.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Sun, Jul 01, 2007 at 07:20:08PM -0700, Eric wrote:
>
> >
> > Everything is always passed as a Datum, so yes, it's is determined by
> > the storage clause in CREATE TYPE.
>
> Still not sure what to do in some scenarios. One example is the gist
> example code for btree (btree_gist). If you loo
>
> Everything is always passed as a Datum, so yes, it's is determined by
> the storage clause in CREATE TYPE.
Still not sure what to do in some scenarios. One example is the gist
example code for btree (btree_gist). If you look at the int4 example
consistent function, it gets an int32 value (p
On Wed, Jun 27, 2007 at 09:32:13AM -0700, Eric wrote:
> In GiST, for each new data type we support we're expected to provide
> (among other things) a function to determine whether a query is
> consistent with a particular index entry (given an operator/
> strategy). I haven't been able to figure o
In GiST, for each new data type we support we're expected to provide
(among other things) a function to determine whether a query is
consistent with a particular index entry (given an operator/
strategy). I haven't been able to figure out when the query value
being passed (arg 1 in the _consistent
