On Mon, 4 Aug 2003, Christopher Kings-Lynne wrote:
> Oleg - have you followed the latest discussion on why tsearch2 isn't
> compilable on FreeBSD?
Nop, Teodor's development machine is FreeBSD and he has no problem :)
We'll look
>
> Chris
>
> - Original Message -
> From: "Oleg Bartunov" <
Oleg - have you followed the latest discussion on why tsearch2 isn't
compilable on FreeBSD?
Chris
- Original Message -
From: "Oleg Bartunov" <[EMAIL PROTECTED]>
To: "Bruce Momjian" <[EMAIL PROTECTED]>
Cc: "PostgreSQL-development" <[EMAIL PROTECTED]>
Sent: Monday, August 04, 2003 1:28 PM
On Sun, 3 Aug 2003, Tom Lane wrote:
> I added code to inline_function to stop inlining if a parameter
> expression to be substituted multiple times has cost greater than
> 10*cpu_operator_cost (which roughly means that it contains more than
> 10 operators or functions).
When is this inlining taki
Bruce, you forgot new contrib/tsearch2 module - full text extension (Oleg,Teodor)
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
I notice you can use the 'DROP TYPE' syntax to drop a domain. Should that
be allowed?
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
What about the interval change in ISO datestyle for zero seconds?
LER
--On Sunday, August 03, 2003 19:30:26 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Here are the changes for 7.4. I am looking for any improvements. This
will be adjusted as we move through beta.
I need to work on the othe
I was working on trigger support for PL/R and ran across this bug in my
own code related to STATEMENT level triggers. I decided to try it in PL/Tcl:
regression=# CREATE FUNCTION tcltrigfunc() RETURNS trigger AS '
regression'#return OK
regression'# ' LANGUAGE pltcl;
CREATE FUNCTION
regression=
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > plpython.c: In function `plpython_call_handler':
> > plpython.c:354: warning: suggest explicit braces to avoid ambiguous `else'
>
> Apparently the Python boys are not familiar with the do {...} while (0)
> trick to ensure that a macro co
I have completed the pgindent run, and the copyright updated to 2003.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtow
Bruce Momjian wrote:
Here are the changes for 7.4. I am looking for any improvements. This
will be adjusted as we move through beta.
Almost anything with my name on it (but certainly all the array and
polymorphic function stuff) could have Tom's too, since he reviewed,
polished, and applied it.
Joe Conway <[EMAIL PROTECTED]> writes:
> plpython.c: In function `plpython_call_handler':
> plpython.c:354: warning: suggest explicit braces to avoid ambiguous `else'
Apparently the Python boys are not familiar with the do {...} while (0)
trick to ensure that a macro containing C statements won't
Tom Lane wrote:
I added code to inline_function to stop inlining if a parameter
expression to be substituted multiple times has cost greater than
10*cpu_operator_cost (which roughly means that it contains more than
10 operators or functions). This seems to cut off the problem nicely,
at least for
Just cvsup'd and built from make clean. Getting this new warning:
make[3]: Entering directory `/opt/src/pgsql/src/pl/plpython'
i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -I. -I/usr/include/python2.2
-I../../../src/include -I/usr/kerberos/include -c -o p
Are folks ready for me to run pgindent?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
No, not for 7.4.
---
snpe wrote:
> On Sunday 03 August 2003 11:30 pm, Bruce Momjian wrote:
> > Here are the changes for 7.4. I am looking for any improvements. This
> > will be adjusted as we move through beta.
> >
> > I n
On Sunday 03 August 2003 11:30 pm, Bruce Momjian wrote:
> Here are the changes for 7.4. I am looking for any improvements. This
> will be adjusted as we move through beta.
>
> I need to work on the other sections of a major release, like a
> compatibility section.
>
>
I said:
> There is some code in the function inliner to abandon inlining if an
> input expression is "too expensive", but its notion of "too expensive"
> is currently just "contains subselects". I'm going to see if it helps
> to reject inlining when the input grows "too large", for some value of
>
Here are the changes for 7.4. I am looking for any improvements. This
will be adjusted as we move through beta.
I need to work on the other sections of a major release, like a
compatibility section.
---
Joe Conway <[EMAIL PROTECTED]> writes:
> But I wonder why it isn't at all a problem when the function is also
> defined STRICT?
Because the inliner doesn't think it can safely inline in that case; the
substituted expression isn't strict and so inlining would potentially
change the semantics.
Tom Lane wrote:
Yeah. The problem is that the SQL function inliner generates an
enormous expression tree from this function definition. 7.3 had no
inliner so no problem.
But I wonder why it isn't at all a problem when the function is also
defined STRICT?
I also looked back at the greatest() exa
On Sun, 2003-08-03 at 14:35, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Yes it would. The solution you have already requires an initdb (changed
> > pg_proc.h), as such will probably need to wait until 7.5 for
> > integration. You might be able to squeeze it in as a contrib module
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It seems to be running out of memory.
> Also worth noting, without STRICT, even a plain EXPLAIN *without*
> ANALYZE causes the problem to show itself.
Yeah. The problem is that the SQL function inliner generates an
enormous expression
Rod Taylor <[EMAIL PROTECTED]> writes:
> Yes it would. The solution you have already requires an initdb (changed
> pg_proc.h), as such will probably need to wait until 7.5 for
> integration. You might be able to squeeze it in as a contrib module for
> 7.4 though.
Given that it also requires gramma
[EMAIL PROTECTED] (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) writes:
> I thought about it, but won't that change the on-disk format? Since
> minor version upgrades aren't supposed to require a dump / restore,
> and I understand 7.4 is already in feature freeze, the earliest
> opportunity for somethi
Lee Kindness <[EMAIL PROTECTED]> writes:
>>> The real change that occurred here is that the individual data fields
>>> go through per-datatype send/receive routines, which in addition to
>>> implementing a mostly machine-independent binary format also provide
>>> defenses against bad input data.
>
On Sun, 2003-08-03 at 10:31, Dag-Erling Smørgrav wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I think a longer term solution would be to add a type to pg_attrdef and
> > a bool for ALWAYS. (Tom?)
>
> I thought about it, but won't that change the on-disk format? Since
> minor version upgrad
Tom,
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > I've attached a patch which lets COPY read in the 7.1 format. However
> > i'm not convinced this is the right way to go - I think the format
> > which is output by 7.4 should be identical to the 7.1 format.
>
> You are gre
Rod Taylor <[EMAIL PROTECTED]> writes:
> I think a longer term solution would be to add a type to pg_attrdef and
> a bool for ALWAYS. (Tom?)
I thought about it, but won't that change the on-disk format? Since
minor version upgrades aren't supposed to require a dump / restore,
and I understand 7.4
> On the other hand, I seem to have botched the definition of
> force_default_value() in include/catalog/pg_proc.h, because adding the
> trigger manually doesn't seem to work either:
>
> | des=# \df force_default_value
> | List of functions
> | Result data type | Sc
As previously mentioned, I'm working on implementing [subject]. I
think I've mostly worked it out, but I'm having trouble with the
GENERATED ALWAYS case.
My changes (see attached patch) can be summarized as follows:
- in backend/utils/adt/misc.c:
- added a force_default_value() function whi
Hello:
Finally after some tests i'm doing this:
SELECT pg_namespace.nspname AS TABLE_SCHEMA,
pg_class.relname AS TABLE_NAME,
pg_attribute.attname AS COLUMN_NAME,
pg_attribute.atttypid AS DATA_TYPE,
pg_attribute.attlen AS COLUMN_SIZE,
pg_attribute.attndims AS COLUMN_DIMENSIONS,
pg_attribute.attnum
31 matches
Mail list logo
