- Original Message -
From: "Dave Page" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Saturday, June 28, 2003 6:55 PM
Subject: Re: [webmaster] [PATCHES] .pot files are unavailable (?)
> It's rumoured that Devrim GUNDUZ
Darko Prenosil writes:
> What happened with hr_HR translations ? They are in 7.3.2, but missing from
> current CVS snapshot, and they are not available from the mentioned link
> either. I also send translations for libpq (that was few days before big
> server crash). Any reason why You decide to d
On Sat, 28 Jun 2003, Kurt Roeckx wrote:
> On Thu, Jun 26, 2003 at 08:02:01AM -0400, Kris Jurka wrote:
> >
> >
> > On Thu, 26 Jun 2003, Manuel Gil [iso-8859-1] Pérez wrote:
> >
> > > Hi all.
> > >
> > > I have a Java application that it connects to the PostgreSQL database with
> > > IPv6 patch in
On Sunday 29 June 2003 12:38, Peter Eisentraut wrote:
> Darko Prenosil writes:
> > What happened with hr_HR translations ? They are in 7.3.2, but missing
> > from current CVS snapshot, and they are not available from the mentioned
> > link either. I also send translations for libpq (that was few da
The attached patches will add
pg_get_ruledef(oid, int)
pg_get_viewdef(text, int)
pg_get_viewdef(oid, int)
pg_get_indexdef(oid, int)
pg_get_constraintdef(oid, int)
pg_get_expr(text, oid, int)
If the last parameter "pretty-print" is 0, these function will return
the same result as
Tom Lane wrote:
If I were you I'd file this on the to-fix-later list and concentrate
on polymorphic aggregates during the next couple days. If that's not
done by Tuesday it will be a tough sell to put in during beta.
Attached is a patch that implements polymorphic aggregates.
Included in the patc
Joe Conway <[EMAIL PROTECTED]> writes:
> Included in the patch, I changed SQL language functions so that they
> could be declared with and use polymorphic types.
I'm not convinced that will work ... in particular, does the parsetree
get fixed correctly when a SQL function is inlined?
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Included in the patch, I changed SQL language functions so that they
could be declared with and use polymorphic types.
I'm not convinced that will work ... in particular, does the parsetree
get fixed correctly when a SQL function is inlined?
I
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Included in the patch, I changed SQL language functions so that they
could be declared with and use polymorphic types.
I'm not convinced that will work ... in particular, does the parsetree
get fixed correctly when a SQL function is inlined?
Joe Conway wrote:
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Included in the patch, I changed SQL language functions so that they
could be declared with and use polymorphic types.
I'm not convinced that will work ... in particular, does the parsetree
get fixed correctly when a SQL func
Joe Conway <[EMAIL PROTECTED]> writes:
> So I'd propose that we put another check in inline_function(), and
> reject attempts to inline functions with polymorphic arguments.
Seems reasonable. Someday we might want to try to make that work,
but not the day before feature freeze...
Hi!
We have written two new files by name datacube.c in tcop
directory and datacube.h in include directory. We have even changed some
exsisting files. We have made a patch of the files that have been
changed.
But how should we send the new files datacube.c, and datacube.h along with
the p
The attached patch enables PL/pgSQL functions (but not triggers) to
accept and return polymorphic types. It is careful to return false from
func_up_to_date() if any of the polymorphic types change from
call-to-call. It also falls back to the pg_proc declared types if the
caller didn't setup the
13 matches
Mail list logo
