Re: [SQL] new idea
On Mon, Apr 09, 2007 at 09:42:24AM +0300, sql4-en.narod.ru wrote: > Let me know your opinion about next way of processing and extracting data. > This would very comfortable for delivery xml-data into any program, for > example into browser. > Has this idea future ? What are you think ? What does this do that inheritance doesn't already do? I don't think I see anything. A -- Andrew Sullivan | [EMAIL PROTECTED] Everything that happens in the world happens at some place. --Jane Jacobs ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] new idea
On Apr 9, 2007, at 7:21 AM, Andrew Sullivan wrote: On Mon, Apr 09, 2007 at 09:42:24AM +0300, sql4-en.narod.ru wrote: Let me know your opinion about next way of processing and extracting data. This would very comfortable for delivery xml-data into any program, for example into browser. Has this idea future ? What are you think ? What does this do that inheritance doesn't already do? I don't think I see anything. I don't really even see the need for inheritance here. This is what most ORMs do at the application level already. erik jones <[EMAIL PROTECTED]> software developer 615-296-0838 emma(r)
Re: [SQL] new idea
On Mon, Apr 09, 2007 at 09:11:57AM -0500, Erik Jones wrote: > > I don't really even see the need for inheritance here. This is what > most ORMs do at the application level already. Wel, sure, but the poster seemed to think that having a way to represent this in the database was a good thing. (I'm not actually convinced even of that. The whole point of SQL was to move away from the hierarchical model, and so grafting a lot of hierarchy back onto it suggests to me that the OP has picked the wrong technology for the problem at the outset.) A -- Andrew Sullivan | [EMAIL PROTECTED] In the future this spectacle of the middle classes shocking the avant- garde will probably become the textbook definition of Postmodernism. --Brad Holland ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] [ADMIN] Another question in functions
On Sun, 8 Apr 2007, Karthikeyan Sundaram wrote: > > Hi team, > > I have a requirement like this. > create table valid_lovs (code_id int not null,lov_value int not null > ,description varchar(256),status bit(1) not null default '1',constraint > lov_pk primary key (code_id,lov_value)); > I need to write 2 functions. > 1) Find_LOV. In this function I will pass only a text message but > should return an array. > create or replace function find_lov_func(in p_1 anyelement, out p_2 > anyarray) as$$ select array[x.code_id, x.lov_value] from valid_lovs x, > valid_lovs y where y.description = $1 and x.code_id = > y.lov_value;$$language sql; Well, I don't think the above does what you want for a couple reasons. First, anyelement/anyarray don't do what you want, they make it so that the output array is of the type that came in from the anyelement. Second, your example shows you getting multiple arrays back AFAICT, which the above also wouldn't do I believe. Perhaps find_lov_func(in p_1 text) returns setof int[] might get closer to your intent. > 2) get_lov function: In this function, I will pass a text field and I > should get an integer and the text as output > for example > create or replace function get_lov_func(in p_1 varchar) returns setof > valid_lovs as$$ select x.lov_value, x.description from valid_lovs x, > valid_lovs y where y.description = $1 and x.code_id = > y.lov_value;$$language sql; In this case you say you're returning a valid_lovs, but you're not, you're only returning some of the fields. Either get all the columns from valid_lovs, make a new type to represent what you're returning or make it return setof record and specify the field information at call time. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] MD5 sums of large objects
Hello Michael, thanks for the comments on my corrected function. You could make a proposal in pgsql-hackers but I think 8.3 is in feature freeze so don't expect to see it until 8.4, if it's accepted at all. There's always PgFoundry :-) I'll now see how this performs in my application and if I'm satisfied with this solution I'll post something on pgsql-hackers of pgfoundry. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [SQL] new idea
On Apr 9, 2007, at 9:14 AM, Andrew Sullivan wrote: On Mon, Apr 09, 2007 at 09:11:57AM -0500, Erik Jones wrote: I don't really even see the need for inheritance here. This is what most ORMs do at the application level already. Wel, sure, but the poster seemed to think that having a way to represent this in the database was a good thing. (I'm not actually convinced even of that. The whole point of SQL was to move away from the hierarchical model, and so grafting a lot of hierarchy back onto it suggests to me that the OP has picked the wrong technology for the problem at the outset.) You're parenthesized comments were what I was getting at. :) erik jones <[EMAIL PROTECTED]> software developer 615-296-0838 emma(r) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
