> > I also quote the PotgreSQL user manual
> >
(http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/arrays.html):
>
> In the contrib/ directory are procedures to search arrays for values.
> This may help.
Thanks for the tip, but in fact I've seen them (and they're listed on the
s
Hello Bruce!
> Yes, we inherited these arrays from Berkeley and haven't had any need to
> remove them. Are you trying to do things that the other interfaces like
> ODBC and JDBC don't handle?
About the groups: I just want to write a function that will return the users
names belonged by a given g
Hi,
I think Bruce meant contrib/intarray which provides incredibly fast
indexed access to arrays of integers, which is your case.
We use it a lot, particularly in our full text search engine (OpenFTS).
regards,
Oleg
On Sat, 20 Oct 2001, Steve Howe wrote:
> > > I also qu
Lee Kindness writes:
> Touche, but the man page for the front-end (plain old cc) doesn't list
> options and only refers to the acc man page ;)
Well, I'm stumped. All the Solaris compilers I've ever seen did support
and document the -Wl option.
> After a simple './configure' on a stock Solaris
Bill Studenmund writes:
> > create function produce(text) returns text as '
> > GD["key"] = args[0]
> > ' language plpython;
> >
> > create function consume() returns text as '
> > return GD["key"]
> > ' language plpython;
> >
> > There is also a dictionary for private data.
>
> Private t
>I think Jean-Michael's comments were right. While I'm not sure if things
>will be as overwhelming as he predicted, packages (even as implimented in
>my patch) will help people develop code libraries for PostgreSQL. And that
>will make PostgreSQL applications easier.
PostgreSQL is a fantastic to
Chris Bitmead <[EMAIL PROTECTED]> writes:
> When I try and load the data into 7.2 it gives
> a bunch of errors like
> \N command not found
You're going to have to be more specific if you want help fixing it...
regards, tom lane
---(end of broadcas
"Johann Zuschlag" <[EMAIL PROTECTED]> writes:
> Here is an excerpt of the original dump-file.
That's what you showed us already. What I'd like to see is the
original database contents, particularly
select * from pg_operator where oid = 280343;
select * from pg_operator where oid
- Original Message -
From: Bill Studenmund <[EMAIL PROTECTED]>
Sent: Sunday, October 14, 2001 8:22 AM
> My description of namespaces seems to have caused a fair bit of confusion.
> Let me try again.
>
> The ability of the package changes to automatically check standard when
> you give a
On Sat, 20 Oct 2001, Peter Eisentraut wrote:
> Yes, you're right. Actually, sharing data across PostgreSQL C functions
> is trivial because you can just use global variables in your dlopen
> modules.
Exactly. That's why I never envisioned "C" or "internal" functions using
package global variabl
On Sat, 20 Oct 2001, Serguei Mokhov wrote:
> > It means that when you want to use one of the built in functions
> > (date_part, abs, floor, sqrt etc.) you don't have to prefix it with
> > "standard.". You can just say date_part(), abs(), floor(), sqrt(), etc.
> > The only time you need to prefix
I just checked out postgresql from CVS, built it and
did a pg_dumpall of my 7.1.3 databases.
When I try and load the data into 7.2 it gives
a bunch of errors like
\N command not found
I guess they are nulls and it can't recognise them
or something.
---(end of broadcast)-
> Thus spake Tom Lane
> > [EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
> > >> BTW, if you are seeing unreclaimed sorttemp files in a recent release
> > >> (7.0 or later), I'd like to know about it. That shouldn't happen,
> > >> short of a backend crash anyway...
> >
> > > Well, I had over 6,000
Thus spake Tom Lane
> [EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
> >> BTW, if you are seeing unreclaimed sorttemp files in a recent release
> >> (7.0 or later), I'd like to know about it. That shouldn't happen,
> >> short of a backend crash anyway...
>
> > Well, I had over 6,000 of these files
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> How about copying the entire argv[] array to a new location before the
> very first call to getopt(). Then you can use getopt() without hackery
> and can do anything you want to the "real" argv area. That should be a
> lot safer. (We don't know yet
Steve Howe writes:
> > The group array is a hack but the pg_proc array would be hard to replace
> > becauseit acts as part of the unique key used for cache lookups.
> This design itself bothers me.
> We have no other option left ? Like arrays being referenced in relations ?
> That's far from per
Tom Lane writes:
> The reason we see this now, and didn't see it before, is that
> I rearranged startup to set the ps process title as soon as possible
> after forking a subprocess --- and at least on Linux machines, that
> "nextchar" pointer is pointing into the argv array that's overwritten
> b
>No argument here. But the proposed Oracle "packages" are something
>completely different and don't solve any of the problems you list.
Hello,
I agree packages are not designed primarily for library installation. I
also agree packages might need dependency checking. But packages can be
dumpe
"Steve Howe" <[EMAIL PROTECTED]> writes:
>> The group array is a hack but the pg_proc array would be hard to replace
>> becauseit acts as part of the unique key used for cache lookups.
> This design itself bothers me.
> We have no other option left ? Like arrays being referenced in relations ?
But what if you want a C function to set a variable which can be
accessed using an SQL, perl, PLpgSQL or other function type?
Shouldn't a global variable be global between all types of functions?
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what
20 matches
Mail list logo
