Darren Duncan writes:
> But I'm just citing numeric as an example; there would be a lot more
> in practice, potentially one for every individual type, so for example
> if operators were defined for the open union rather than for the base
> type, then users/extensions could define their own types a
To follow-up my earlier comments ...
I suspect for practical purposes we may want to limit the scope of some type
features.
For example, the greatest benefits for "open union" / "mixin" types is with
routines/operators, not so much with tables.
So, Pg could choose to support open unions but
Robert Haas wrote:
On Wed, May 11, 2011 at 11:43 AM, Joseph Adams
wrote:
On Tue, May 10, 2011 at 5:19 PM, Darren Duncan wrote:
Examples of open union types could be number, which all the numeric types
compose, and so you can know say that you can use the generic numeric
operators on values yo
On Wed, May 11, 2011 at 11:43 AM, Joseph Adams
wrote:
> On Tue, May 10, 2011 at 5:19 PM, Darren Duncan
> wrote:
>> Examples of open union types could be number, which all the numeric types
>> compose, and so you can know say that you can use the generic numeric
>> operators on values you have si
Excerpts from Simon Riggs's message of mar may 10 17:57:20 -0400 2011:
> On Wed, May 4, 2011 at 5:58 PM, Alvaro Herrera
> wrote:
> > both Oracle and MS-SQL have it
>
> Do they? What types are they called?
ANYTYPE
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Rep
On Wed, May 11, 2011 at 7:53 AM, Robert Haas wrote:
> That's likely to be how it gets implemented, but you seem to have
> missed the point of some of the discussion upthread: the big problem
> with that is that someone might type "DROP TYPE foo", and when they
> do, you need an efficient way to fi
On 05/11/2011 07:53 AM, Robert Haas wrote:
On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
wrote:
It seems to me a reasonable way to implement VARIANT would be to have
a data type called VARIANT that stores an OID of the inner type at the
beginning, followed by the binary data.
That's likely
On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
wrote:
> It seems to me a reasonable way to implement VARIANT would be to have
> a data type called VARIANT that stores an OID of the inner type at the
> beginning, followed by the binary data.
That's likely to be how it gets implemented, but you see
2011/5/11 Joseph Adams :
> On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
> wrote:
>> The VARIANT type, or similar, would be useful for the JSON data type
>> I've been intermittently working on, as it would allow us to create a
>> function like this:
>>
>> from_json(JSON) returns VARIANT
>
> Th
On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
wrote:
> The VARIANT type, or similar, would be useful for the JSON data type
> I've been intermittently working on, as it would allow us to create a
> function like this:
>
> from_json(JSON) returns VARIANT
This occurred to me: if PostgreSQL func
It seems to me a reasonable way to implement VARIANT would be to have
a data type called VARIANT that stores an OID of the inner type at the
beginning, followed by the binary data. When you say
pg_typeof(somevariant), you'll get 'variant'. Instead, you'd use a
function like this:
variant_typ
On Tue, May 10, 2011 at 3:57 PM, Simon Riggs wrote:
> On Wed, May 4, 2011 at 5:58 PM, Alvaro Herrera
> wrote:
>
> > A customer came to us with this request: a way to store "any" data in a
> > column. We've gone back and forth trying to determine reasonable
> > implementation restrictions, safet
On Wed, May 4, 2011 at 5:58 PM, Alvaro Herrera wrote:
> A customer came to us with this request: a way to store "any" data in a
> column. We've gone back and forth trying to determine reasonable
> implementation restrictions, safety and useful semantics for them.
> I note that this has been requ
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mar may 10 16:21:36 -0400 2011:
Darren Duncan wrote:
To follow-up, an additional feature that would be useful and resembles union
types is the variant where you could declare a union type first and then
separately other types could
Excerpts from Bruce Momjian's message of mar may 10 16:21:36 -0400 2011:
> Darren Duncan wrote:
> > To follow-up, an additional feature that would be useful and resembles
> > union
> > types is the variant where you could declare a union type first and then
> > separately other types could decla
Darren Duncan wrote:
> To follow-up, an additional feature that would be useful and resembles union
> types is the variant where you could declare a union type first and then
> separately other types could declare they are a member of the union. I'm
> talking about loosely what mixins or type-r
To follow-up, an additional feature that would be useful and resembles union
types is the variant where you could declare a union type first and then
separately other types could declare they are a member of the union. I'm
talking about loosely what mixins or type-roles or interfaces etc are in
Thanks for picking up on my mentioning union types; I wasn't sure if anyone did.
Merlin Moncure wrote:
On Fri, May 6, 2011 at 3:18 PM, Andrew Dunstan wrote:
On 05/06/2011 04:08 PM, Alvaro Herrera wrote:
Excerpts from Darren Duncan's message of mié may 04 15:33:33 -0300 2011:
I see VARIANT/
On Fri, May 6, 2011 at 3:18 PM, Andrew Dunstan wrote:
>
>
> On 05/06/2011 04:08 PM, Alvaro Herrera wrote:
>>
>> Excerpts from Darren Duncan's message of mié may 04 15:33:33 -0300 2011:
>>
>>> I see VARIANT/ANYTYPE as the most general case of supporting union types,
>>> which,
>>> say, could have m
Alvaro Herrera writes:
> Excerpts from Darren Duncan's message of mié may 04 15:33:33 -0300 2011:
>> I see VARIANT/ANYTYPE as the most general case of supporting union types,
>> which,
>> say, could have more specific examples of "allow any number or date here but
>> nothing else". If VARIANT
On 05/06/2011 04:08 PM, Alvaro Herrera wrote:
Excerpts from Darren Duncan's message of mié may 04 15:33:33 -0300 2011:
I see VARIANT/ANYTYPE as the most general case of supporting union types, which,
say, could have more specific examples of "allow any number or date here but
nothing else".
Excerpts from Darren Duncan's message of mié may 04 15:33:33 -0300 2011:
> I see VARIANT/ANYTYPE as the most general case of supporting union types,
> which,
> say, could have more specific examples of "allow any number or date here but
> nothing else". If VARIANT is supported, unions in gener
On 05/05/2011 01:00 PM, Jim Nasby wrote:
On May 4, 2011, at 6:24 PM, Andrew Dunstan wrote:
I'm far from convinced that storing deltas per column rather than per record is
a win anyway. I don't have hard numbers to hand, but my vague recollection is
that my tests showed it to be a design that
On May 4, 2011, at 6:24 PM, Andrew Dunstan wrote:
> I'm far from convinced that storing deltas per column rather than per record
> is a win anyway. I don't have hard numbers to hand, but my vague recollection
> is that my tests showed it to be a design that used more space.
It depends on how man
On Wed, May 4, 2011 at 8:03 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> As a followup idea there exists the desire to store records as records
>> and not text representation of same (given differing record types, of
>> course), for which it'd be more worthwhile.
>
> Maybe. The conventional w
Alvaro Herrera writes:
> As a followup idea there exists the desire to store records as records
> and not text representation of same (given differing record types, of
> course), for which it'd be more worthwhile.
Maybe. The conventional wisdom is that text representation of data is
more compact
Excerpts from Tom Lane's message of mié may 04 20:05:54 -0300 2011:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of mié may 04 14:36:44 -0300 2011:
> >> Just out of curiosity, what actual functionality gain would ensue over
> >> just using text? It seems like doing anything usefu
"David E. Wheeler" writes:
> On May 4, 2011, at 3:04 PM, Alvaro Herrera wrote:
>> As someone commented downthread, they also want to have things such as a
>> "typeof" operator. It could be used in (say) a plpgsql function to
>> choose different branches of code.
> FWIW, pg_typeof(any) has been i
On 05/04/2011 07:05 PM, Tom Lane wrote:
Alvaro Herrera writes:
Excerpts from Tom Lane's message of mié may 04 14:36:44 -0300 2011:
Just out of curiosity, what actual functionality gain would ensue over
just using text? It seems like doing anything useful with the audit
table contents would
On May 4, 2011, at 3:04 PM, Alvaro Herrera wrote:
> As someone commented downthread, they also want to have things such as a
> "typeof" operator. It could be used in (say) a plpgsql function to
> choose different branches of code.
FWIW, pg_typeof(any) has been in core since 9.0.
Best,
David
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié may 04 14:36:44 -0300 2011:
>> Just out of curiosity, what actual functionality gain would ensue over
>> just using text? It seems like doing anything useful with the audit
>> table contents would still require casting the column t
Excerpts from Tom Lane's message of mié may 04 14:36:44 -0300 2011:
> Alvaro Herrera writes:
> > The main idea is to be able to store column values in an audit table
> > like this:
> > old_valuevariant
> > new_valuevariant
> > Currently, they use text for old_value and new_value, but this
On Wed, May 4, 2011 at 2:55 PM, Andrew Dunstan wrote:
> On 05/04/2011 01:36 PM, Tom Lane wrote:
>>
>>> The main idea is to be able to store column values in an audit table
>>> like this:
>>> old_value variant
>>> new_value variant
>>> Currently, they use text for old_value and new_valu
On 05/04/2011 01:36 PM, Tom Lane wrote:
The main idea is to be able to store column values in an audit table
like this:
old_value variant
new_value variant
Currently, they use text for old_value and new_value, but this is, of
course, not very satisfactory.
Just out of curiosity,
On Wed, May 4, 2011 at 12:36 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> A customer came to us with this request: a way to store "any" data in a
>> column. We've gone back and forth trying to determine reasonable
>> implementation restrictions, safety and useful semantics for them.
>
> Yes,
Alvaro Herrera wrote:
A customer came to us with this request: a way to store "any" data in a
column. We've gone back and forth trying to determine reasonable
implementation restrictions, safety and useful semantics for them.
I note that this has been requested in the past:
http://archives.postg
Alvaro Herrera writes:
> A customer came to us with this request: a way to store "any" data in a
> column. We've gone back and forth trying to determine reasonable
> implementation restrictions, safety and useful semantics for them.
Yes, it seems rather messy.
> The main idea is to be able to s
Alvaro Herrera wrote:
> A customer came to us with this request: a way to store "any" data
> in a column.
+1
More than once (usually in replication, interface, or audit
situations) I've had to create a table with one column each of a
number of different data types, only one of which will be
Hello,
A customer came to us with this request: a way to store "any" data in a
column. We've gone back and forth trying to determine reasonable
implementation restrictions, safety and useful semantics for them.
I note that this has been requested in the past:
http://archives.postgresql.org/pgsql-
39 matches
Mail list logo
