Added to TODO:
Allow the creation of "distinct" types
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php
---
Peter Eisentraut wrote:
> Here is an implementation of distinct types, known fr
I have a feeling what it would actually take to make this useful might
be to turn every type into a kind of polymorphic type like our anyelem
and anyarray. So substring(mystring) would work and return a mystring
but mystring=string would fail.
--
greg
--
Sent via pgsql-hackers mailing list (pgs
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> If it's going to take a significant amount of work then I think
someone
> ought to provide an actual justification why it's worth the work.
This by itself doesn't justify the effort, but I've worked with
databases which would refuse to allow comparison (
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On Friday 28 November 2008 18:49:17 Tom Lane wrote:
>> The problem I see with distinct types is that the typing is *too*
>> strong --- the datatype has in fact got no usable operations whatever.
> You are supposed to define your own. It's a new type
On Friday 28 November 2008 18:49:17 Tom Lane wrote:
> > * Strong typing is preferable in complex applications to avoid errors
> > like sum(ordinal_column). Most developers use this all the time in their
> > 3GL code but cannot use it in SQL.
>
> The problem I see with distinct types is that the typ
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2008-11-28 at 11:20 -0500, Tom Lane wrote:
>> If it's going to take a significant amount of work then I think someone
>> ought to provide an actual justification why it's worth the work.
> Few thoughts:
> * Domains don't work very well in conjunc
On Fri, 2008-11-28 at 11:20 -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> Shame, this was sorely needed.
>
> > I understand, but the work required to make it work properly is too much
> > under the commit fest spirit right now.
>
> Personally
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Shame, this was sorely needed.
> I understand, but the work required to make it work properly is too much
> under the commit fest spirit right now.
Personally I was wondering exactly why it's "sorely needed". There has
been no
On Nov 28, 2008, at 5:09 PM, Andrew Dunstan wrote:
Speaking of other sorts of derived types: might they include
something just like enums, but sorting on the string values defined
for the enum rather than on the order in which the values were
defined in the enum? I'd use something like that
David E. Wheeler wrote:
Speaking of other sorts of derived types: might they include something
just like enums, but sorting on the string values defined for the enum
rather than on the order in which the values were defined in the enum?
I'd use something like that all the time…
order b
On Nov 28, 2008, at 12:46 PM, Peter Eisentraut wrote:
I understand, but the work required to make it work properly is too
much under the commit fest spirit right now. In particular, I'm
thinking we should try to devise a clever way to make the CREATE
ORDERING facility that SQL has for user
Simon Riggs wrote:
On Tue, 2008-11-25 at 12:21 +0200, Peter Eisentraut wrote:
Peter Eisentraut wrote:
Here is an implementation of distinct types,
I'm withdrawing this patch from the current commit fest for further
work. For the record, I have attached the current patch, including the
docume
On Tue, 2008-11-25 at 12:21 +0200, Peter Eisentraut wrote:
> Peter Eisentraut wrote:
> > Here is an implementation of distinct types,
>
> I'm withdrawing this patch from the current commit fest for further
> work. For the record, I have attached the current patch, including the
> documentation
Peter Eisentraut wrote:
Here is an implementation of distinct types,
I'm withdrawing this patch from the current commit fest for further
work. For the record, I have attached the current patch, including the
documentation work by Jeff Davis.
Index: doc/src/sgml/ref/create_domain.sgml
===
Tom Lane wrote:
That's an artifact of the fact that the patch tries to piggyback on
the DOMAIN infrastructure instead of implementing its own statement
type etc.
This piggybacking is intentional in some way. If you read the
commentary on the SQL99 standard, distinct types were specifically
i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Jeff Davis wrote:
>> postgres=# create type mytype as int;
>> CREATE DOMAIN
> Is that really the return message we want?
That's an artifact of the fact that the patch tries to piggyback on
the DOMAIN infrastructure instead of implementing its own state
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Sat, 2008-11-01 at 16:38 -0400, Tom Lane wrote:
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>>> There is an implicit AS ASSIGNMENT cast between the base type and the
>>> distinct
>>> type in each direction.
>>
>> Hmm ... so out-of-the-box, a distin
Jeff Davis wrote:
postgres=# create type mytype as int;
CREATE DOMAIN
Is that really the return message we want?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, 2008-11-07 at 09:39 -0800, Jeff Davis wrote:
> On Sat, 2008-11-01 at 16:38 -0400, Tom Lane wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > On Friday 31 October 2008 17:01:05 Kevin Grittner wrote:
> > >> (1) Can you compare a literal of the base type?
> >
> > > No, unless you
On Sat, 2008-11-01 at 16:38 -0400, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > On Friday 31 October 2008 17:01:05 Kevin Grittner wrote:
> >> (1) Can you compare a literal of the base type?
>
> > No, unless you create additional casts or operators.
>
> >> (2) Can you expli
On Fri, 2008-11-07 at 09:11 -0800, David E. Wheeler wrote:
> On Nov 6, 2008, at 11:51 PM, Jeff Davis wrote:
>
> > It needs documentation, and I included a quick patch for that (if
> > that's
> > helpful).
>
> You mis-spelled "cast" as "case".
>
Thanks. Updated diff attached.
Regards,
On Fri, 2008-10-31 at 16:03 +0200, Peter Eisentraut wrote:
> Here is an implementation of distinct types, known from SQL99 and
> beyond. They are like domains, except that they don't have defaults or
> constraints and they do not allow implicit casting to their base type.
> The latter aspect is wh
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On Friday 31 October 2008 17:01:05 Kevin Grittner wrote:
>> (1) Can you compare a literal of the base type?
> No, unless you create additional casts or operators.
>> (2) Can you explicitly cast to the base type?
> There is an implicit AS ASSIGNMEN
On Friday 31 October 2008 17:01:05 Kevin Grittner wrote:
> I notice there's no documentation yet. Do you have a reference to a
> good description of the feature, consistent with your implementation?
Documentation will need to be added, of course, but there isn't really a lot
to describe: you cre
>>> Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Here is an implementation of distinct types, known from SQL99 and
> beyond. They are like domains, except that they don't have defaults
or
> constraints and they do not allow implicit casting to their base
type.
> The latter aspect is what make
Here is an implementation of distinct types, known from SQL99 and
beyond. They are like domains, except that they don't have defaults or
constraints and they do not allow implicit casting to their base type.
The latter aspect is what makes them distinct types. They are useful to
create more t
Here is an implementation of distinct types, known from SQL99 and
beyond. They are like domains, except that they don't have defaults or
constraints and they do not allow implicit casting to their base type.
The latter aspect is what makes them distinct types. They are useful to
create more type
27 matches
Mail list logo
