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
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
> 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
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
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
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
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.
>
[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
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
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
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.
---
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.
>
>
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
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
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
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
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.
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
>
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
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
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.
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
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 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=
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
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
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
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)
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 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" <
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
31 matches
Mail list logo
