Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
What I'm proposing should be an addition that also can be seen as the
beginning of a path to migrate the CREATE TYPE construct to conform with
the SQL 2003 standard.
I'd be interested to see where in the SQL2003 spec the synt
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> What I'm proposing should be an addition that also can be seen as the
> beginning of a path to migrate the CREATE TYPE construct to conform with
> the SQL 2003 standard.
I'd be interested to see where in the SQL2003 spec the syntax you are
proposing
I'm not suggesting that we remove the current way of doing things. I
understand that if we did that, it would cause problem for everyone that
has created scalar types up to this day. What I'm proposing is an
alternative way of doing this, not a replacement. And as things stand
today, I'd be hap
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Ok, so there are two 'optional' arguments. Following my suggestion, the
> input and receive function would always take 3 arguments. Then, it's up
> to the function as such if it makes use of them or not. Do you see any
> problem with that?
(1) backw
Martijn van Oosterhout wrote:
The docs are your friend, see[1] in particular the input_function and
the receive_function.
[1] http://www.postgresql.org/docs/8.1/interactive/sql-createtype.html
Ok, so there are two 'optional' arguments. Following my suggestion, the
input and receive function
On Sun, Feb 12, 2006 at 07:33:30PM +0100, Thomas Hallgren wrote:
> >Very little, as it makes unjustifiable assumptions about all the
> >datatype's support functions being predictably propertied. (There's
> >more than one possible signature, let alone any secondary properties
> >such as volatility
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
What do you think of my earlier suggestion. Skip all the 'create function' statements and
just add the "AS 'filename' LANGUAGE C" to the CREATE TYPE.
Very little, as it makes unjustifiable assumptions about all the
datatype's
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> What do you think of my earlier suggestion. Skip all the 'create function'
> statements and
> just add the "AS 'filename' LANGUAGE C" to the CREATE TYPE.
Very little, as it makes unjustifiable assumptions about all the
datatype's support functions be
Tom Lane wrote:
Martijn van Oosterhout writes:
On Thu, Feb 09, 2006 at 09:33:35AM -0500, Tom Lane wrote:
You'd have to go over a lot of code with a fine-tooth comb before
putting this ability into the hands of ordinary users, else you'd be
creating loopholes for DOS attacks (or worse).
Woul
Martijn van Oosterhout writes:
> On Thu, Feb 09, 2006 at 09:33:35AM -0500, Tom Lane wrote:
>> You'd have to go over a lot of code with a fine-tooth comb before
>> putting this ability into the hands of ordinary users, else you'd be
>> creating loopholes for DOS attacks (or worse).
> Would it be r
On Thu, Feb 09, 2006 at 09:33:35AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Actually, I'm think this whole automatic creation of a shell-type a bit
> > silly anyway. Why not simply solve the problem directly like so:
>
> > CREATE TYPE complex AS SHELL;
>
> One of the unwritten
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
In particular, it seems unsafe to use a Java class as a PG UDT,
because the method pointers wouldn't remain the same across
backend runs.
I'm not sure I understand what you mean.
Doesn't a Java o
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In particular, it seems unsafe to use a Java class as a PG UDT,
>> because the method pointers wouldn't remain the same across
>> backend runs.
>>
> I'm not sure I understand what you mean.
Doesn't a Java object contain a method-tab
Tom Lane wrote:
Martijn van Oosterhout writes:
Actually, I'm think this whole automatic creation of a shell-type a bit
silly anyway. Why not simply solve the problem directly like so:
CREATE TYPE complex AS SHELL;
One of the unwritten consequences of the way that it works
Martijn van Oosterhout writes:
> Actually, I'm think this whole automatic creation of a shell-type a bit
> silly anyway. Why not simply solve the problem directly like so:
> CREATE TYPE complex AS SHELL;
One of the unwritten consequences of the way that it works now is that
only superusers can "
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
I'd like to enable UDT's written in Java
Does Java really give you enough control over the bit-level
representation of an object for this goal to be considered sane?
Most definitely yes!
In particular, it seems unsafe t
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I'd like to enable UDT's written in Java
Does Java really give you enough control over the bit-level
representation of an object for this goal to be considered sane?
In particular, it seems unsafe to use a Java class as a PG UDT,
because the method po
Martijn van Oosterhout wrote:
On Thu, Feb 09, 2006 at 01:53:13PM +0100, Thomas Hallgren wrote:
If you look at the code it says in a comment:
/*
* Only C-coded functions can be I/O functions. We
enforce this
* restriction here m
On Thu, Feb 09, 2006 at 01:53:13PM +0100, Thomas Hallgren wrote:
> >If you look at the code it says in a comment:
> >
> >/*
> > * Only C-coded functions can be I/O functions. We
> > enforce this
> > * restriction here mainly to preve
Martijn van Oosterhout wrote:
On Thu, Feb 09, 2006 at 01:08:01PM +0100, Thomas Hallgren wrote:
Hi,
I'd like to enable UDT's written in Java and made some initial trial and
error. I don't get very far. Here's what I do:
I take the 'complex' type example described in '31.11 User-Defined
Types'
On Thu, Feb 09, 2006 at 01:08:01PM +0100, Thomas Hallgren wrote:
> Hi,
> I'd like to enable UDT's written in Java and made some initial trial and
> error. I don't get very far. Here's what I do:
>
> I take the 'complex' type example described in '31.11 User-Defined
> Types' and change it to use
Hi,
I'd like to enable UDT's written in Java and made some initial trial and
error. I don't get very far. Here's what I do:
I take the 'complex' type example described in '31.11 User-Defined
Types' and change it to use Java functions (see below). But I get:
ERROR: type "complex" does not e
22 matches
Mail list logo
