> Can any one give me a link/tutorial for using arrays in databases..I
> need Queries to access the arrays as well...
A quick search in Google.Com yielded a number of results which included
the following:
PostgreSQL Tutorial
http://www.eskimo.com/support/P
[sNip]
> In order to make this work with postgres an additional table is needed
> that can hold the level (depth) of the branch because pgsql doesn't like
> returning a tuple that isn't based on a defined structure. Once you've
> created this table you can pretty much forget about it.
>
> CREATE T
> Where can i find a tutorial on PL/PGSQL?.Help me by
> listing some sites to guide me in this context.
Does the following meet your needs?
Chapter 19. PL/pgSQL - SQL Procedural Language
http://www.sql.org/sql-database/postgresql/manual/plpgsql.html
--
Ra
[sNip]
> See connectby() in contrib/tablefunc. Someone was working on SQL99
> recursive queries but it didn't get done for 7.4 -- perhaps it will be
> in 7.5. In the meantime, connectby() is in 7.3 and might work for you.
Oracle 8i doesn't seem to have any special indexing to handle this
> is here nobody? Is this group closed?
I see that your question wasn't answered. There are people around
here, but it looks like the activity is a bit scattered -- some newsgroups
are much busier, such as Novell.Com's DeveloperNet and SpamCop.Net's help
newsgroups, while there are oth
[sNip]
>> I have been considering using "calculated index" or "computed index"
>> but dunno if that really conveys anything.
>
> Well, "Expression Indexes" is the most accurate. Or "Expression-Based
> Indexes."
What is the proposed definition of an "Expression Index?"
When I se
>> For example, if I want to index on a date field but only have the index
>> keep track of the most recent 30 days (and then create a secondary
>> index for all dates) so as to improve performance on more heavily
>> loaded systems.
>>
>> Am I understanding this new terminology correctly? Thank
[sNip]
> It's the same in this case. The tree building stuff only ever looks down
> so the level returned in the query results will start at 1 no matter
> where you enter your tree. In our case we could enter the tree at
> 'node' 100 and get the tree below that but the function will start at 1
> b
>> You're in need of the "CONNECT BY" option which is ideal for
>> scenarios such as yours. Unfortunately PostgreSQL doesn't have it
>> yet, but I believe there is a PLSQL script (or something like this)
>> which emulates the CONNECT BY behaviour and it's called "connectby()"
>> or something l
> As subj says. A simple menu is defined in a table. But how to extract
> it? Heres the deal:
>
> Table menu has these 3 columns: menuidparentmenudesc
>
> Ok this should be easy right? Those menu-rows that has parent=0 is
> "toplevel". And so forth. An example:
>
> 10"Items"
> 2
[sNip]
>> bearing in mind that this index can be used with queries that contain
>> WHERE conditions like "create_date >= some-date-constant". The planner
>> must be able to convince itself that the right-hand side of the WHERE
>> condition is >= the cutoff in the index's predicate condition. Sinc
11 matches
Mail list logo
