software and I'd rather choose all the
defaults myself rather than try to talk a novice user through setting
up PG.
I wrote a VB wrapper and install PG from an embedded resource. It
handles all the messy details that technologically challenged users
might face.
---
Stefan Berglund
then.
pgInstaller certainly isn't dead - it's the installer for the official windows
binary releases of PostgreSQL.
I should have been a bit more explicit in that I wrap pgInstaller simply
to control all the command line options.
---
Stefan Berglund
---(end of broadcast
a little odd:
SELECT *
FROM
fn_Split_List('5,1,3') SL INNER JOIN
test_table T ON SL=T.ID;
Stefan Berglund
www.horseshowtime.com
Online Show Entry - Instant Internet Horse Show Schedules and Results
[EMAIL PROTECTED]
tel 714.968.9112 fax 714.968.5940
---(end of broadcast
On Sat, 10 Mar 2007 00:37:08 -0500, [EMAIL PROTECTED] (Tom Lane) wrote:
in [EMAIL PROTECTED]
Stefan Berglund [EMAIL PROTECTED] writes:
Below is a small test case that illustrates what I'm attempting which is
to provide a comma separated list of numbers to a procedure which
subsequently uses
a little odd:
SELECT *
FROM
fn_Split_List('5,1,3') SL INNER JOIN
test_table T ON SL=T.ID;
---
Stefan Berglund
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining
from an
array to a table?
---
This posting is provided AS IS with no warranties and no guarantees either
express or implied.
Stefan Berglund
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Mon, 12 Mar 2007 10:41:21 -0400, [EMAIL PROTECTED] (Tom Lane) wrote:
in [EMAIL PROTECTED]
Stefan Berglund [EMAIL PROTECTED] writes:
On Sat, 10 Mar 2007 00:37:08 -0500, [EMAIL PROTECTED] (Tom Lane) wrote:
It looks pretty ugly to me too, but you haven't explained your problem
clearly enough
some_table T ON F=T.id;
If the SRF returns a composite type then you can use the function name
qualified by any of the members of the list of types.
SELECT *
FROM
foo() F INNER JOIN
some_table T ON F.num=T.id;
---
Stefan Berglund
---(end of broadcast
On Thu, 15 Mar 2007 09:47:27 -0500, [EMAIL PROTECTED] (George Weaver)
wrote:
in [EMAIL PROTECTED]
Stefan Berglund wrote:
foo WHERE (ID = 53016 OR ID = 27 OR ID = 292 OR ID = 512) or I could
alternatively pass the string of IDs ('53016,27,292,512') to a table
returning function which TABLE
On Thu, 15 Mar 2007 15:46:33 -0500, [EMAIL PROTECTED] (Bruno Wolff III)
wrote:
in [EMAIL PROTECTED]
On Mon, Mar 12, 2007 at 11:15:01 -0700,
Stefan Berglund [EMAIL PROTECTED] wrote:
I have an app where the user makes multiple selections from a list. I
can either construct a huge WHERE
of the show. Since each trainer can have anywhere
from one to thirty or forty horses in their barn you can do the math to
see that the list of IDs passed from the app to the database can be
anywhere from a single ID up to possibly thousands of IDs.
---
Stefan Berglund
---(end
the
extraneous LOOP and I'm more than happy with the performance. What's
funny is that the function as it now stands is what I initially obtained
by googling, but I mistakenly added the extra loop. :-)
What I finally came up with is here:
[EMAIL PROTECTED]
---
Stefan Berglund
best bet, but I'd like to add that the best
way to do this to never create your database(s) other than via script
and then you automatically have what you need by default. :-)
---
Stefan Berglund
---(end of broadcast)---
TIP 6: explain analyze is your
.
Is there a piece I've missed or is this incorrect installation behavior?
Thank you for any light that you can shed on my problem.
---
Stefan Berglund
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
14 matches
Mail list logo
