On 30 Nov 2002, Neil Conway wrote:
> On Sat, 2002-11-30 at 12:47, Stephan Szabo wrote:
> > check constraints with subselects.
>
> Have we decided how this would even work? Last I heard, Tom still had
> some major reservations about the practicality of implementing these --
> for example, would yo
On Sat, 30 Nov 2002, Christopher Kings-Lynne wrote:
> Is there any reason why the tseach indexes couldn't be modified to just work
> on TEXT fields and not TXTIDX fields. Is there really a reason to have the
> TXTIDX type?
>
> I mean, when the index is created over the text column, instead of jus
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> pg_dump, our upgrade process is painful enough having to do a dump,
> reload. I think we should be able to guarantee (or at least let
> much closer to it) that the process works in all cases.
I would already be happy if pg_dump backed up my dat
On Sunday 01 December 2002 05:03, Tom Lane wrote:
> Paul Ramsey <[EMAIL PROTECTED]> writes:
> > Oracle has finally surpassed PostgreSQL in some elements of
> > object-relational technology. Among the things you can do are:
> >
> > - Address components of objects using dot-notation. (select
> > empl
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On 30 Nov 2002, Neil Conway wrote:
>> Have we decided how this would even work? Last I heard, Tom still had
>> some major reservations about the practicality of implementing these --
>> for example, would you re-evaluate all constraints that SELECT from a
"Nicolai Tufar" <[EMAIL PROTECTED]> writes:
> From: "Tom Lane" <[EMAIL PROTECTED]>
>> Ohhh ...
>>
>> Nicolai, are you running with a client encoding different from server
>> encoding?
> Got it!
Okay, the problem is a double free of memory in COPY OUT. I've applied
the following patch for 7.3.1.
On Sun, 1 Dec 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On 30 Nov 2002, Neil Conway wrote:
> >> Have we decided how this would even work? Last I heard, Tom still had
> >> some major reservations about the practicality of implementing these --
> >> for example, would you
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A grotty answer is to not apply constant-expression folding to table
>> function RTE entries. A better answer would be to make
>> ExecMakeTableFunctionResult more flexible, but I'm not quite sure what
>> it should do if presented a non-fu
> > I was thinking more along the lines of ALTER TABLE a.b RENAME TO x.y
> >
> > I don't see anything in the SQL spec about this; anyone know what
> > precedent is in Oracle or other DBMSes?
>
> Good question. I can't find anything in the Oracle docs indicating it is
even
> possible. We should prob
Tom Lane wrote:
> If the parser treated PUBLIC as an actual keyword, you'd not be having
> this problem, because keywords are case-folded on an ASCII-only basis
> (which is consistent with the SQL99 spec, amazingly enough).
>
> We put in the above hack after someone complained that PUBLIC didn't u
> Joe Conway <[EMAIL PROTECTED]> writes:
>> If presented with a non-function-call expression tree, can we always evaluate
>> it to produce a scalar constant (if it isn't already)? If so, why not do that,
>> create a one row, one column tuplestore, and exit? It's really no different
>> than a funct
Why are the features provided by PostGIS not added to the core of
PostgreSQL?
Hans
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Bruce Momjian <[EMAIL PROTECTED]> writes:
> PUBLIC doesn't seem like a very common column name --- seems safe to
> make it reserved. We made 'value' reserved in 7.3, and that was a much
> more common one.
I'm still quite unhappy about 'value', and would like to look into
making it unreserved agai
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We made 'value' reserved in 7.3, and that was a much
> more common one.
BTW, you mean "current" not "7.3". That patch has still got some
serious problems anyway:
7.3:
regression=# select value;
ERROR: Attribute "value" not found
HEAD:
regression=#
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We made 'value' reserved in 7.3, and that was a much
> > more common one.
>
> BTW, you mean "current" not "7.3". That patch has still got some
> serious problems anyway:
Yes, I realized later it was current. I was fixing the dbdpg r
Hi guys,
Was just looking at the project page for Compiere, an Open Source
ERP+CRM solution that is usually in the top 10 most popular SourceForge
projects.
They were attempting to port Compiere from Oracle to PostgreSQL, but
have stopped (apparently) because PostgreSQL doesn't support "embedded
Christopher Kings-Lynne wrote:
possible. We should probably just go with your suggestion. Anything else
beyond the relnamespace and pg_depend entries that need to be dealt with?
What about sequences for serial columns? What about views or types that
depend on the table?
Yeah, good point. I t
On Sunday, December 1, 2002, at 10:49 AM, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
PUBLIC doesn't seem like a very common column name --- seems safe to
make it reserved. We made 'value' reserved in 7.3, and that was a
much
more common one.
I'm still quite unhappy about 'valu
> > regression=# select value;
> > ERROR: Attribute "value" not found
> >
> > HEAD:
> >
> > regression=# select value;
> > server closed the connection unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> > The connec
> > regression=# select value;
> > ERROR: Attribute "value" not found
> >
> > HEAD:
> >
> > regression=# select value;
> > server closed the connection unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> > The connec
> This is sort of we had thought about full text searching in postgres and
> what should happens with maturity of tsearch. We began from contrib/module
> just to get some experience and still need to do some research on
> underlying algorithms. Also, remember current GiST is not concurrent and
> w
Hans-Jürgen Schönig wrote:
> Why are the features provided by PostGIS not added to the core of
> PostgreSQL?
Because they are GPL licensed. Some also thought it would be better as
a separate project that could release independently.
--
Bruce Momjian| http://candle.ph
Han Holl's recent complaint about memory leaks in SQL-language functions
has started me thinking again about making plan trees read-only to the
executor. This would make it a lot easier to manage memory cleanly in
the SQL function executor, and would eliminate a lot of plan tree
copying that curre
Tom Lane wrote:
Either of these approaches would mean that we couldn't easily "just
execute" a scalar expression tree, which is something that we do in
quite a few places (constraint checking for instance). There would need
to be some advance setup done. With the Param-style approach, the
advanc
Justin Clift wrote:
> Hi guys,
>
> Was just looking at the project page for Compiere, an Open Source
> ERP+CRM solution that is usually in the top 10 most popular SourceForge
> projects.
>
> They were attempting to port Compiere from Oracle to PostgreSQL, but
> have stopped (apparently) because P
Reading through their web page, they seem to have decided to try and
fund moving their transactional issues into the Java container instead
of getting nested transactions into PostgreSQL. It sounds retrograde and
risky, but I suppose if they carry it off, they will attain true
database independ
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Either of these approaches would mean that we couldn't easily "just
>> execute" a scalar expression tree, which is something that we do in
>> quite a few places (constraint checking for instance). There would need
>> to be some advance se
The PostGIS project has been making use of GiST for about a year now and
(thanks to the excellent work of Oleg and Teodor) have found it to be a
most excellent indexing system.
We are about to apply for some government R&D funding, and one of our
potential subprojects is creating GiST bindings
Paul Ramsey <[EMAIL PROTECTED]> writes:
> So far, GiST is integrated into the main tree, but all the bindings seem
> to be kept outside, in contrib (ltree, btree, rtree).
This is a historical artifact. As GiST comes more up-to-speed, the
operator classes for it should become mainstream.
> Would
Tom Lane wrote:
Right at the moment I'm struggling a bit with terminology. We've got
basically four categories of node types to deal with in this scheme:
Plan steps Expressions
(Scan, Sort, etc) (Var, Op, Func, etc)
Planner output "Plan" "Expr"?
Executor state "CommonState" ???
Th
Joe Conway <[EMAIL PROTECTED]> writes:
>> Any ideas about naming are welcome.
> Maybe:
> Plan steps Expressions
> -
> Planner output"Plan" "Expr"
> Executor state
Is there a known problem with TOAST tables growing indefinitely in 7.2?
We have a database that has large text chunks inserted & deleted regularly,
and despite regular vacuums, the toast table continues to grow. We can not
do a VACUUM FULL since it's a 24x7 system, but we do VACUUM frequently.
David Wheeler wrote:
My understanding is that the nul character is legal in a byte sequence,
but if it's not properly escaped, it'll be parsed as the end of the
statement. Unfortunately, I think that it's a very tough problem to solve.
No question wrt '\0' bytes -- they would have to be escaped
Bruce Momjian wrote:
Justin Clift wrote:
Hi guys,
Was just looking at the project page for Compiere, an Open Source
ERP+CRM solution that is usually in the top 10 most popular SourceForge
projects.
They were attempting to port Compiere from Oracle to PostgreSQL, but
have stopped (apparently) b
Joe Conway wrote:
>
> Has anyone from Compiere ever contacted this list to discuss their issues? It
> is an unbelievable shame that the most active open source ERP can't use an
> open source database.
I think so, but not with zeal.
:-/
Regards and best wishes,
Justin Clift
> Joe
--
"My g
Philip Warner <[EMAIL PROTECTED]> writes:
> Is there a known problem with TOAST tables growing indefinitely in 7.2?
No. The index on the toast table may well bloat, because it's tracking
a moving range of toast-item OIDs. But the table itself should be okay
so long as it's vacuumed regularly.
I
At 12:37 AM 2/12/2002 -0500, Tom Lane wrote:
If you're seeing bloat while using plain (not full) vacuums, my guess
would be that you need to enlarge the FSM parameters in postgresql.conf.
Good call; they are still default (1 pages) and we are seeing 26000
pages per day being updated:
NOTIC
Philip Warner <[EMAIL PROTECTED]> writes:
> Is there any way (other than VACUUM FULL) to recover the current lost space?
Probably not. Plain VACUUM will reclaim any empty pages it happens to
see at the end of the table, but without a VACUUM FULL you won't get any
proactive effort to make the end-
38 matches
Mail list logo
