On 15 Nov 2013, at 8:04 pm, Chris Travers chris.trav...@gmail.com 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
On Sun, Nov 17, 2013 at 6:57 PM, Tony Theodore tony.theod...@gmail.comwrote:
On 15 Nov 2013, at 8:04 pm, Chris Travers chris.trav...@gmail.com 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
On 16 Nov 2013, at 3:01 am, Merlin Moncure mmonc...@gmail.com 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
On 18 Nov 2013, at 2:24 pm, Chris Travers chris.trav...@gmail.com 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
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,
description text,
...
primary key (source_system,
On Fri, Nov 15, 2013 at 2:01 AM, Tony Theodore tony.theod...@gmail.com 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
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 declared as follows:
CREATE TYPE my_grid AS (min_x double precision,
On Mon, Jun 18, 2012 at 4:23 PM, Chris Schnaufer
chris.schnau...@pictometry.com 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
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,
col3 text not null
);
CREATE INDEX i_test_tab_col1 ON test_tab( col1 );
On Mon, Jan 11, 2010 at 5:14 AM, Vincenzo Romano
vincenzo.rom...@notorand.it 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
2010/1/11 Merlin Moncure mmonc...@gmail.com:
On Mon, Jan 11, 2010 at 5:14 AM, Vincenzo Romano
vincenzo.rom...@notorand.it 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
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
2010/1/11 Merlin Moncure mmonc...@gmail.com:
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
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 benefits of a composiite type
insofar as it essentially lets
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 benefits of a composiite type
insofar as it essentially lets
On Tue, Oct 6, 2009 at 4:43 PM, Postgres User
postgres.develo...@gmail.com 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
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:
Well,
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 is
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
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 you
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:
Hello,
for some reason, I couldn't get an answer on the novice-list, so if
this is the wrong place to ask or if it's just in the manual, excuse me
and just drop me a hint to the place where I have to look for it...
As far as I understand from the (excellent, btw.) PostgreSQL
documentation,
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 value
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 any
Folks,
Composite types look so seductive for mapping application-level
non-scalar objects to columns:
o) Directly mappable to a client-side datatype via oid w/o any
heavyweight O/R code.
o) Such mapping persists through any use of views, joins, etc from
ad-hoc queries.
o) Using Domains as
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
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
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 28
I'd like to compute some row like results and return them from a
function (and pass the result to PHP[*]).
Well I've read about composite type but all the references I've seen
are about coding in C. That's not the way I'd like to follow by now.
I was expecting to declare composite types in
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
Are there any plans for PostGreSQL to support something like the following
without having to write specialized C code for each type? (or maybe it
already does?)
create type a_type ( field_a int, field_b int );
create table a_table ( a_column a_type );
If i try this now, i get column
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 straight
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
Hi,
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. Here is a case. Suppose I define a
[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
35 matches
Mail list logo
