On 18 Nov 2013, at 2:24 pm, Chris Travers wrote:
>
> I haven't done work with this so I am not 100% sure but it seems to me based
> on other uses I have for table inheritance that it might work well for
> enforcing interfaces for natural joins. The one caveat I can imagine is that
> there ar
On 16 Nov 2013, at 3:01 am, Merlin Moncure wrote:
>
> Well, here are the downsides. Composite types:
> *) are more than the sum of their parts performance-wise. So there is
> a storage penalty in both the heap and the index
> *) can't leverage indexes that are querying only part of the key
> *
On Sun, Nov 17, 2013 at 6:57 PM, Tony Theodore wrote:
>
> On 15 Nov 2013, at 8:04 pm, Chris Travers wrote:
> >
> > In general, if you don't know you need composite types, you don't want
> them. You have basically three options and the way you are doing it is the
> most typical solution to the pr
On 15 Nov 2013, at 8:04 pm, Chris Travers wrote:
>
> In general, if you don't know you need composite types, you don't want them.
> You have basically three options and the way you are doing it is the most
> typical solution to the problem
The current way is much easier since I discovered th
On Fri, Nov 15, 2013 at 2:01 AM, Tony Theodore wrote:
> Hi,
>
> I was reading about composite types and wondering if I should use them
> instead of composite keys. I currently have tables like this:
>
> create table products (
> source_system text,
> product_id text,
> des
On Mon, Jun 18, 2012 at 4:23 PM, Chris Schnaufer
wrote:
> I am getting an “invalid input syntax for type double precision” error when
> I return an array as part of a composite type from my C-language function. I
> can re-create this situation with just a type and a function.
>
>
>
> My type is de
2010/1/11 Merlin Moncure :
> On Mon, Jan 11, 2010 at 11:08 AM, Vincenzo Romano > SELECT * FROM master_tab
>> WHERE col1>='a date':timestamp AND col1<'another date'::timestamp
>> AND col2=42 AND col3='the answer';
>
> queries of this sort are optimally handled via row constructor for 8.2
> onwards
On Mon, Jan 11, 2010 at 11:08 AM, Vincenzo Romano > SELECT * FROM master_tab
> WHERE col1>='a date':timestamp AND col1<'another date'::timestamp
> AND col2=42 AND col3='the answer';
queries of this sort are optimally handled via row constructor for 8.2 onwards:
create index col231_idx on master
2010/1/11 Merlin Moncure :
> On Mon, Jan 11, 2010 at 5:14 AM, Vincenzo Romano
> wrote:
>> Hi all.
>>
>> It's not clear to me how composite values are used in conditions
>> (WHERE/CHECK).
>> In my case I have something like this:
>>
>> -- begin snippet
>>
>> CREATE TABLE test_tab (
>> col1 times
On Mon, Jan 11, 2010 at 5:14 AM, Vincenzo Romano
wrote:
> Hi all.
>
> It's not clear to me how composite values are used in conditions
> (WHERE/CHECK).
> In my case I have something like this:
>
> -- begin snippet
>
> CREATE TABLE test_tab (
> col1 timestamp not null,
> col2 int8 not null,
>
On Tue, Oct 6, 2009 at 4:43 PM, Postgres User
wrote:
> Browsing the docs last night, I realized that I've never taken
> advantage of Postgres' powerful composite types. But a question came
> to mind- in what scenarios should you use a composite type in a table
> structure? That is, I can see the
On Dec 20, 2007 4:40 AM, Wolfgang Keller <[EMAIL PROTECTED]> wrote:
> I'm not sure whether I am violating some copyright, so I didn't want to
> post the SQL script here. But the script is publicly downloadable at
> www.mimosa.org, and I only need a part of it to explain the basic
> concept. So this
Hello,
and thanks again for your reply.
And excuse me for taking so long to reply.
I wanted to simplify the schema and make it more "readable" for
clueless morons like me. >;->
Simplifying the schema is fine (and good!) as long as it exhibits the
same behavior as the more complex one:
Wel
On Nov 19, 2007, at 6:17 , Wolfgang Keller wrote:
I wanted to simplify the schema and make it more "readable" for
clueless morons like me. >;->
Simplifying the schema is fine (and good!) as long as it exhibits the
same behavior as the more complex one: often in the course of
simplifying
Hello,
and thanks for your reply.
I'm sorry, but I'm apparently too dump to actually figure out
myself whether this means that I can use a single composite type
column as a primary / foreign key or whether not...?
What have you actually tried?
I wanted to simplify the schema and make it mor
On Nov 16, 2007, at 4:07 , Wolfgang Keller wrote:
But I am pathetically lazy >;->, so I ld like to save keystrokes
and thus I had the (maybe pathetic)idea to use composite types for
the composite primary (and foreign) keys. No luck again, it seems
to me, as according to the documentation:
Tom Lane <[EMAIL PROTECTED]> writes:
> you cannot enter such a thing as a row of a table, for example, and that is
> the basic property that any rowtype ought to have no?
Well that logic would apply equally to any SQL datatype. You can't perform
arithmetic on NULL and that's the basic property an
David J N Begley <[EMAIL PROTECTED]> writes:
> So... why can I assign NULL to a composite type column in a table but not to a
> composite type variable in PL/pgSQL? Is there any way to force that "out"
> composite type variable to be NULL?
In general the distinction between a true null composite
James Robinson <[EMAIL PROTECTED]> writes:
> That said -- anyone stepping up to claiming using 'em? Are these things
> seen as against the data normalization grain?
One strike against 'em is the fairly high overhead involved --- a
composite value is stored as effectively its own tuple, so there's
On Apr 29, 2005, at 12:21 PM, Tom Lane wrote:
My recollection is that there are some pretty serious limitations on
what you can do in this line, but basic cases do work. I think the
lack
of an ALTER TYPE that can handle the same cases is just a matter of
lack
of round tuits.
regards, tom lan
James Robinson <[EMAIL PROTECTED]> writes:
> Hmm -- I see that if the composite type was created via a table
> definition, then you _can_ actually add and drop columns, and the
> tables using the composite type seem to get updated, as in
> http://archives.postgresql.org/pgsql-hackers/2005-
This has been recently covered in a discussion both on this list and on
Hackers. It is not easy to do, apparently, but it is on the radar.
Check the archives.
Best Wishes,
Chris Travers
On Tuesday 02 March 2004 09:53, you wrote:
> Are there any plans for PostGreSQL to support something like th
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I appreciate any help I can get on this...Recently, I've been experimenting
> > with the user defined base-types (using CREATE TYPE) with successful results.
> > But, when it comes to handling classes as composite types, things are not
> > as straigh
Tom,
Thanks for your feedback and insight. Consider this: Wouldn't it be
fantastically powerful and also type-behavior-consistent if user-defined
composite types (using CREATE TABLE) behave somewhat similar to base types
defined by CREATE TYPE? Again, going back to the earlier example,
the compos
[EMAIL PROTECTED] writes:
> I appreciate any help I can get on this...Recently, I've been experimenting
> with the user defined base-types (using CREATE TYPE) with successful results.
> But, when it comes to handling classes as composite types, things are not
> as straight forward.
The function-r
25 matches
Mail list logo
