3 ms·

"Now, it's rare that you are likely to get that into phone numbers..." That was part of my point -- if your entire business revolves around phone numbers, beca

"Now, it's rare that you are likely to get that into phone numbers..." That was part of my point -- if your entire business revolves around phone numbers, because you are a phone company or something, then maybe a custom data type makes sense. Then do it, and do it right. But if you think of a phone number as "something to call" then all you need to do is display it to the right person at the right time, and ensure that it reasonably matches something you can type on a phone. And that sounds more like a domain over a text field with a constraint, to me. "I use custom types a lot for defining output tuples for stored procedures" I don't really consider composite types "custom" types any more than an enum is a custom type. Maybe I misunderstood gfodor's statement.

einhverfr 14y ago
With the ability to define columns which store composite types, the line between a custom data type in C and a composite type plus casts is blurring. Back in the 7.x line at one point I discovered that you could do something like: create table foo (...); create table bar (myfoo foo); And this table would be write-only, and indeed the backend would crash when reading from it. That's the only really interesting bug I ever found in PostgreSQL. However, I made the case that it would be nice to be able to treat tuples as full-fledged data types and now by at least 8.1, that was supported. So now I can: create type foo as (...); -- works with create table too create function foo_to_text .....; create function text_to_foo ....; create cast...... create table bar (my_foo foo); insert into bar (my_foo) values ('my.foo.as.text'::text); So the point is that composite types can now be used to blur the lines quite a bit between traditional custom types and the roles that composite types are traditionally used for. You can go a long way prototyping what is useful with composite types, and then later do that right in C.

einhverfr 14y ago

With the ability to define columns which store composite types, the line between a custom data type in C and a composite type plus casts is blurring. Back in the 7.x line at one point I discovered that you could do something like: create table foo (...); create table bar (myfoo foo); And this table would be write-only, and indeed the backend would crash when reading from it. That's the only really interesting bug I ever found in PostgreSQL. However, I made the case that it would be nice to be able to treat tuples as full-fledged data types and now by at least 8.1, that was supported. So now I can: create type foo as (...); -- works with create table too create function foo_to_text .....; create function text_to_foo ....; create cast...... create table bar (my_foo foo); insert into bar (my_foo) values ('my.foo.as.text'::text); So the point is that composite types can now be used to blur the lines quite a bit between traditional custom types and the roles that composite types are traditionally used for. You can go a long way prototyping what is useful with composite types, and then later do that right in C.