"Chris Travers" <[EMAIL PROTECTED]> writes:
> AFAICS, there are only one thing missing and it could probably be worked
> around if the backend did nto crash when you try to retrieve the information
> via a casting function. It is:
> Some way to define a standard input and output representation (ho
> (To avoid confusion since we're talking about complex numbers, I'm
> assuming you mean what PostgreSQL refers to as composite types.) It
> definitely would be nice to be able to define composite types that can
> be used as attributes and functions. It seems like there's quite a bit
> of, er, func
On Jan 2, 2004, at 7:44 AM, Chris Travers wrote:
creating a complex type and using it in a table would create the same
problem, would it not?
If my type has more than one component, then it would not work well.
After a bit of experimentation, I see what you mean:
test=# select version();
Hi all.
OS: Tru64 UNIX 4.0d
PG: PostgreSQL v7.4.1
PY: Python v2.3.3
I just ran into a minor bug while compiling
PL/Python module. It bombed out on lines 153 and 160 of
./src/pl/plpython/plpython.c complaining on incomplete type
"PyObject_HEAD".
The source of the problem were these two
On Fri, 2 Jan 2004, Bruce Momjian wrote:
> Marc removed a warez site on gborg.postgresql.org yesterday, and now we
> are getting packet flooded on our main PostgreSQL servers. I am sure
> Marc is on top of this problem and will resolve it soon.
Actually, it turns out the problem wasn't just our
Note that I haven't made many changes to the postgresql.conf file, so
there might be something really obvious I've overlooked, but here are the
uncommented ones (ie. ones I've modified from defaults):
tcpip_socket = true
max_connections = 512
shared_buffers = 1 # min 16, at least max_
Baldur Norddahl wrote:
Quoting Martijn van Oosterhout <[EMAIL PROTECTED]>:
...
You could create a new operator, but that means you'll have difficulty
moving it to any database that doesn't have that operator (which is most of
them).
Any commercial database vendor would be happy to make such
Marc removed a warez site on gborg.postgresql.org yesterday, and now we
are getting packet flooded on our main PostgreSQL servers. I am sure
Marc is on top of this problem and will resolve it soon.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
Dennis Haney <[EMAIL PROTECTED]> writes:
> I was looking at pull_up_subqueries
> (backend/optimizer/prep/prepjointree.c 135) and I was wondering why the
> recursive optimization is only done on subqueries that can be optimized.
Because it will be done when the subquery is planned (via recursion
Hi
I was looking at pull_up_subqueries
(backend/optimizer/prep/prepjointree.c 135) and I was wondering why the
recursive optimization is only done on subqueries that can be optimized.
As in, why isn't the code like:
if (rte->rtekind == RTE_SUBQUERY) {
subquery = copyObject(subquery);
creating a complex type and using it in a table would create the same
problem, would it not?
If my type has more than one component, then it would not work well.
Here is a better example. Imagine creating a type for complex numbers.
Each complex number has 2 components: a real component (x, nume
Actually, I already had a few thousand lines of code done (using PHP's MySQL
functions) and I needed an abstraction layer to conform to my existing code.
In this case, if an application has been written with PHP's MySQL functions,
porting it to this layer would be simple and straightforward, with
Hi,
On Fri, 2004-01-02 at 14:20, Arjen van der Meijden wrote:
> Are those two LIGHT weight?
> Afaik, PEAR (DB) affects the performance of your OO-php-app quite bad,
> but I haven't really tested it very often myself, just seen tests by others?
> And I'm not talking "quite bad, because php is not
Enver ALTIN wrote:
Hi,
On Fri, 2004-01-02 at 13:38, Chris Travers wrote:
A few years ago, I set about porting a PHP application from MySQL to
PostgreSQL, after realizing that MySQL wasn't going to be able to handle it.
In order to do this, I built a light, fast database abstraction layer which
c
Hi,
On Fri, 2004-01-02 at 13:38, Chris Travers wrote:
> A few years ago, I set about porting a PHP application from MySQL to
> PostgreSQL, after realizing that MySQL wasn't going to be able to handle it.
> In order to do this, I built a light, fast database abstraction layer which
> conforms to th
Hi all;
Here is a brief guide to NULL's and Referential Integrity:
NULL is a special SQL value meaning 'unknown.' Well, it is a little more
complicated and NULL can mean "value does not exist." Therefore X = NULL is
NULL becuase we don't know if the NULL is equal to X. So:
NULL does not equal
Hi all;
A few years ago, I set about porting a PHP application from MySQL to
PostgreSQL, after realizing that MySQL wasn't going to be able to handle it.
In order to do this, I built a light, fast database abstraction layer which
conforms to the behavior of the MySQL functions in PHP. This means
If you have a language installed (like pl/pgsql), then dropping the public
schema also drops the language. Ouch.
Maybe there is a solution to that one though...
John Sidney-Woollett
Kris Jurka said:
>
>
> On Wed, 31 Dec 2003, Mike Nolan wrote:
>
>> That raises an interesting question. Can pg be
18 matches
Mail list logo
