Trond Eivind Glomsrød wrote:
> Postgresql doesn't support upgrades[1], so if we're going to release
> upgrades[2], we'd need the backported fixes for 6.5, 7.0 and 7.1
>
> [1] Not the first time I mention this, is it?
There is now /contrib/pg_upgrade. It has all the things I can think of
for up
Tatsuo Ishii wrote:
> >I hope you won't make this standard practice. Because there are quite
> >significant differences that make upgrading from 7.1.x to 7.2 troublesome.
> >I can't name them offhand but they've appeared on the list from time to time.
>
> I tend to agree above but am not sure m
Tom Lane wrote:
> Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > OK I'm starting to get it :). Will the index behaviour be changed soon?
>
> When someone steps up and does it. I've learned not to predict
> schedules for this project.
It is not that hard to implement, just messy. When the index r
Rod Taylor wrote:
> > INSERT INTO t1 (c1) VALUES (1), (2);
> >
> > would be executed in a similar fashion to:
> >
> > INSERT INTO t1 (c1) VALUES (1);
> > INSERT INTO t1 (c1) VALUES (2);
> >
> > Does this sound reasonable?
Sounds good to me.
> I debated doing the above too. In f
Hi hackers!
I would like to add configurablity to my language handler function, now it is compiled
in. Is there any api in the server to do this?
thanx:
Laszlo Hornyak
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Hmm... I think there is some confusion here.
Oleg and Teodor updated the GiST indexing to be null safe for postgresql 7.2.
The changes we made to PostGIS were just to allow our spacial indexing
support functions to work with the changes made in the actual GiST indexing
code (the GiST interface
Tom Lane wrote:
>>3. PL/pgSQL support for returning sets -- this seems to me like an
>>important item if SRFs are to be useful to the masses. Any pointers on
>>how to approach this would be appreciated.
>>
>
>Does Oracle's pl/sql support this? If so what does it look like?
>
Oracle supports "p
On Sun, 2002-05-26 at 21:55, Joe Conway wrote:
> Tom Lane wrote:
> >>3. PL/pgSQL support for returning sets -- this seems to me like an
> >>important item if SRFs are to be useful to the masses. Any pointers on
> >>how to approach this would be appreciated.
> >
> > Does Oracle's pl/sql support
Hannu Krosing wrote:
> On Sun, 2002-05-26 at 21:55, Joe Conway wrote:
>
>>Tom Lane wrote:
>>
3. PL/pgSQL support for returning sets -- this seems to me like an
important item if SRFs are to be useful to the masses. Any pointers on
how to approach this would be appreciated.
>>>
>>>Do
> (OTOH one could make a good argument that now is the time to do it
> if we're ever gonna do it --- clients that are not schema-aware will
> be badly in need of work anyway for 7.3...)
Maybe the attisdropped column should be created and added to the
pg_attribute catalog now as well. It would al
Joel Burton writes:
> I've lived without having this bite me; I'd think that side-effect functions
> would be unusual in a WHERE clause. I'm just wondering if we should work
> this into the docs somewhere. (Or is it? I took a look, but didn't see
> anything).
I've written up a section about it w
Tom Lane writes:
> On HPUX 10.20, using perl 5.6.1, plperl builds without complaint but
> SIGSEGV's upon use. AFAIR this worked last time I tried it; any idea
> what you might have changed?
I have written it so that the commands that are executed during the build
should be the same. Can you se
Katherine Ward writes:
> A few of the identifier names used in postgres collide with WIN32 or MFC names.
Does Windows and/or MFC make any kind of statement about what kinds of
identifiers it reserves for its own use?
> b. GetUserName() => GetUserNameFromId()
> c. GetCurrentTime()
13 matches
Mail list logo
