From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Command Prompt, Inc(dot)" <pgsql-general(at)commandprompt(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: CREATE TYPE delimiter? |
Date: | 2001-11-03 21:05:48 |
Message-ID: | 2942.1004821548@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Command Prompt, Inc." <pgsql-general(at)commandprompt(dot)com> writes:
> Wonderful. While you're in there, you might look at the wording on the
> input and output function descriptions; it says that they must take either
> one or two arguments of type opaque, but it's not at all clear what the
> second argument would be for, in either circumstance.
On checking the code, that's actually wrong, as well as insufficient.
Fixed.
> Also, the DEFAULT clause was a bit curious; it says you can describe "some
> specific bit pattern" to mean "data not present"; presumably in place of
> NULL?
This is bogus too. A default value is just a default value supplied at
the datatype level instead of the column level. Basically INSERT does
this for each column:
* Column value given explicitly in INSERT command?
=> use it
* DEFAULT specified for column in table creation command?
=> use that
* DEFAULT specified for column's datatype?
=> use that
* Else, insert a NULL
There isn't anything in there that could allow a datatype-specific
representation of NULL, which is what the existing wording seems to
suggest the clause is for.
> I figured this meant it took a bit string for some kind of internal
> handling, but it seems to accept any arbitrary value I give it (integer,
> text, though not a b'1001' style bit string!). However, I got some ugly
> disconnections from the server after experimenting with this value, and
> attempting to SELECT values that would have otherwise been NULL. ;) I
IIRC, until recently the datatype-level DEFAULT was essentially useless,
because the way it was coded, you'd have to enter a textual string whose
contents are the *internal* representation of the desired default value.
This is pretty silly, so it's been fixed to accept a normal
external-form string that gets fed through the type's input routine.
But I think that may only be in 7.2, not any earlier release.
I'm working on improving the CREATE TYPE ref page now ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Ridge | 2001-11-03 21:08:43 | Re: SETOF and language 'plpgsql' |
Previous Message | K. Ari Krupnikov | 2001-11-03 20:08:52 | EXCEPT performace |