I've come upon a misbehaviour of drop column, where drop column
unconditionally drops inherited column from child tables.
What it should do is to check if the same column is not inherited from
other parents and drop it only when it is not
Here is the test case:
hannu=# create table p1(id int,
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: 12 September 2002 00:53
To: Dave Page
Cc: Oliver Elphick; [EMAIL PROTECTED]
Subject: Re: [HACKERS]
OK, I am going to add these items to the open items list
because I am having trouble keeping track of
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: 12 September 2002 06:27
To: Justin Clift
Cc: PostgreSQL Hackers Mailing List
Subject: Re: [HACKERS] PGXLOG variable worthwhile?
Also, I have heard symlinks are available in native Windows
but the
On Wed, Sep 11, 2002 at 04:36:31PM -0400, Tom Lane wrote:
IIRC, the conclusion of our earlier debate about backend PREPARE/EXECUTE
syntax was that since it was not implementing exactly the behavior
specified for embedded SQL (and couldn't, not being an embedded
operation) it would be better
On Thu, 2002-09-12 at 00:52, Philip Warner wrote:
At 12:31 PM 9/09/2002 +0100, Oliver Elphick wrote:
3. A view is being created before one of the tables it refers to.
Should not views be created only at the very end?
This would be trivial (and we already put several items at the end), but I
Mike Mascari wrote:
snip
In Windows 2000 and Windows XP with an NTFS filesystem,
Microsoft has added Reparse Points, which allow for the
implementation of symbolic links for directories. Microsoft
calls them Junctions. I *believe* the function used for
creating reparse points is
Michael Meskes [EMAIL PROTECTED] writes:
I'm awfully sorry that I missed this thread. But I do not really
understand the problem. If we cannot be exactly as specified why aren't
we coming close? As it stands now I have to implement my own
PREPARE/EXECUTE in ecpg and the syntax does clash with
Hannu Krosing [EMAIL PROTECTED] writes:
I've come upon a misbehaviour of drop column, where drop column
unconditionally drops inherited column from child tables.
What it should do is to check if the same column is not inherited from
other parents and drop it only when it is not
Hm. Seems
On Thu, 2002-09-12 at 16:14, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I've come upon a misbehaviour of drop column, where drop column
unconditionally drops inherited column from child tables.
What it should do is to check if the same column is not inherited from
other
On Thu, Sep 12, 2002 at 09:07:20AM -0400, Tom Lane wrote:
Michael Meskes [EMAIL PROTECTED] writes:
I'm awfully sorry that I missed this thread. But I do not really
understand the problem. If we cannot be exactly as specified why aren't
we coming close? As it stands now I have to implement
Bruce Momjian [EMAIL PROTECTED] writes:
Well, our whole goal was to get rid of the opaque thing entirely so I am
not sure if we want to keep that going. In fact, I am not sure it is
even possible to remap opaque because it now is represented by so many
other values.
We do still allow OPAQUE
Tom Lane dijo:
Hannu Krosing [EMAIL PROTECTED] writes:
I've come upon a misbehaviour of drop column, where drop column
unconditionally drops inherited column from child tables.
What it should do is to check if the same column is not inherited from
other parents and drop it only when it
Hannu Krosing [EMAIL PROTECTED] writes:
Hm. Seems like attisinherited should have been a count, not a boolean.
Is anyone sufficiently excited about this issue to force an initdb to
fix it?
The count approach seems definitely the right way, but a check (possibly
a slow one) can be probably
On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
Does anyone see a cleaner answer than re-allowing OPAQUE for PL
handlers?
Can't you just special case the language handlers when dumping 7.3 and
change 'RETURNS opaque' to 'RETURNS language_handler'? That's all that
is needed to let them be
Oliver Elphick [EMAIL PROTECTED] writes:
On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
Does anyone see a cleaner answer than re-allowing OPAQUE for PL
handlers?
Can't you just special case the language handlers when dumping 7.3 and
change 'RETURNS opaque' to 'RETURNS language_handler'?
At 10:31 AM 12/09/2002 -0400, Tom Lane wrote:
Does anyone see a cleaner answer than re-allowing OPAQUE for PL
handlers?
What about extending the function manager macros to know about return types
(at least for builtin types)?
On Thu, 12 Sep 2002, Justin Clift wrote:
Mike Mascari wrote:
snip
In Windows 2000 and Windows XP with an NTFS filesystem,
Microsoft has added Reparse Points, which allow for the
implementation of symbolic links for directories. Microsoft
calls them Junctions. I *believe* the function
Does anyone know if such effort is also required to pl/python to become
schema aware?
Regards,
Greg Copeland
On Wed, 2002-09-11 at 19:24, Bruce Momjian wrote:
Patch applied. Thanks.
---
Joe Conway
On Thu, 12 Sep 2002, Justin Clift wrote:
Am just wondering if we've ever considered adding a PGXLOG environment
variable that would point to the pg_xlog directory?
IMHO, a much better way to support this is to put this information into
the config file. That way it can't easily change when you
scott.marlowe wrote:
On Fri, 13 Sep 2002, Justin Clift wrote:
Would it be correct to say that the 'ln' command in the MS Resource Kit
creates this kind of shortcut too, as the Reparse Points feature doesn't
seem to be possible under NT4?
I wouldn't assume that. It's been years since I
Oliver Elphick wrote:
On Thu, 2002-09-12 at 15:54, Tom Lane wrote:
Oliver Elphick [EMAIL PROTECTED] writes:
On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
Does anyone see a cleaner answer than re-allowing OPAQUE for PL
handlers?
I wrote:
scott.marlowe wrote:
I wouldn't assume that. It's been years since I tested it, but back
then, the command line and all program I used could see the link
created by ln that came with the resource kit. They were distinctly
different from the shortcut type of links, in that
Philip Warner [EMAIL PROTECTED] writes:
At 10:31 AM 12/09/2002 -0400, Tom Lane wrote:
Does anyone see a cleaner answer than re-allowing OPAQUE for PL
handlers?
What about extending the function manager macros to know about return types
(at least for builtin types)?
Er ... what has that
Oliver Elphick [EMAIL PROTECTED] writes:
On Thu, 2002-09-12 at 15:54, Tom Lane wrote:
Only if people dump their old databases with 7.3 pg_dump; which is an
assumption I'd rather not make if we can avoid it.
I don't understand.
The only pg_dump we can fix is 7.3.
Certainly. But if we hack
Hi,
Does anyone know any implementation of a fixpoint operator (recursive
queries) for postgreSQL?
Thanks,
Luciano.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Bruce Momjian [EMAIL PROTECTED] writes:
I would love to say that this is related to change in casts, but that
isn't the case. It is the new double-precision handling of dates;
You've got that exactly backwards: date_part has always returned double.
regards, tom lane
Hi everyone,
We're looking to get an initial PostgreSQL Advocacy and Marketing site
up an running in the next day or so.
Whilst we know of a reasonable number of large places running PostgreSQL
(as shown on the
http://techdocs.postgresql.org/techdocs/supportcontracts.php page),
we're still
Barry Lind [EMAIL PROTECTED] writes:
... I don't understand
why the timings for prepared statements would be less than for a regular
statement, and especially why using bind variables would be better than
without. I am concerned that prepared statements may be choosing a
different execution
Giles Lean [EMAIL PROTECTED] writes:
Rod Taylor [EMAIL PROTECTED] writes:
ALTER TABLE FKTABLE ADD FOREIGN KEY(ftest1) references
pktable(ptest1);
NOTICE: ALTER TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
+ ERROR: Relation pg_temp_5. does not exist
That's pretty
Bruce Momjian writes:
Wow. That is clear. Why are we returning year as a double?
Because we've been doing that for many years.
I would love to say that this is related to change in casts, but that
isn't the case.
Sure it is. The float=int casts need to be made implicit, or we'll have
Alvaro Herrera writes:
Is there some documentation on TOAST?
No. Why do you need any?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Fri, 13 Sep 2002, Peter Eisentraut wrote:
Alvaro Herrera writes:
Is there some documentation on TOAST?
No. Why do you need any?
I think I saw some docs in the
/usr/local/src/postgresql-7.2.1/src/backend/access/heap/tuptoaster.c
file on my box. :-)
Actually it is pretty well
At 01:37 PM 12/09/2002 -0400, Tom Lane wrote:
What about extending the function manager macros to know about return
types
(at least for builtin types)?
Er ... what has that got to do with this?
When a user issues a 'CREATE FUNCTION' call, the fmgr can check the return
type, and create it
En 12 Sep 2002 17:23:41 +0200
Hannu Krosing [EMAIL PROTECTED] escribió:
The other sad thing about the current behaviour is that in addition to
being wrong it also breaks dump/reload - after dump/reload the initially
dropped column is back in c1.
I hadn't read this paragraph before. But I
Philip Warner [EMAIL PROTECTED] writes:
At 01:37 PM 12/09/2002 -0400, Tom Lane wrote:
Er ... what has that got to do with this?
When a user issues a 'CREATE FUNCTION' call, the fmgr can check the return
type, and create it with the correct return type (with warning). We just
need to make
Alvaro Herrera [EMAIL PROTECTED] writes:
If this is not clear, imagine the following situation:
create table p1(id int, name text);
create table p2(id2 int, name text);
create table c1(age int) inherits(p1,p2);
create table gc1() inherits (c1);
p1 and p2 have name-attisinherited=0, while
At 11:27 PM 12/09/2002 -0400, Tom Lane wrote:
You mean hardwire the names plpgsql_language_handler, etc, as being
ones that should return such-and-such instead of OPAQUE?
No; I actually mean modifying the function definition macros
(PG_FUNCTION_INFO etc) to allow function definitions to
Hackers,
I'm starting to read the existing algorithms for btree index shrinking.
Right now I'm at 1996 SIGMOD proceedings, Zou and Salzberg On-line
Reorganization of Sparsely-populated B+-trees.
What I want to know is how different from B+-trees are PostgreSQL
B-trees; I've read the README in
At 01:42 PM 13/09/2002 +1000, Philip Warner wrote:
Not all functions would need to use these, but when a user defines a
function they could be checked. And in the case of the plpgsql handlers,
they would of course be defined.
ISTM that this problem comes about because we allow an external
Philip Warner [EMAIL PROTECTED] writes:
ISTM that this problem comes about because we allow an external function to
be defined incorrectly (ie. the db says it returns type A, the function
really returns type B) - and we should be addressing that problem.
Well, yeah. 7.3 is trying to
Hello!
I recommend two good sources of information in English:
http://www.nist.gov/dads/ further look for balanced trees and kins
(BTW, there is some other interesting algorithms alike patricia).
and well-known Donald Knuth's monography, namely, volume 3. (I mean
The Art of Computer
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
I would love to say that this is related to change in casts, but that
isn't the case.
Sure it is. The float=int casts need to be made implicit, or we'll have
tons of problems like this.
Well, yeah. That did not seem to
En Thu, 12 Sep 2002 23:40:21 -0400
Tom Lane [EMAIL PROTECTED] escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
If this is not clear, imagine the following situation:
create table p1(id int, name text);
create table p2(id2 int, name text);
create table c1(age int) inherits(p1,p2);
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
I would love to say that this is related to change in casts, but that
isn't the case.
Sure it is. The float=int casts need to be made implicit, or
we'll have
tons of problems like this.
Well, yeah. That did not
En Fri, 13 Sep 2002 00:46:00 -0400
Tom Lane [EMAIL PROTECTED] escribió:
Peter Eisentraut [EMAIL PROTECTED] writes:
Sure it is. The float=int casts need to be made implicit, or we'll have
tons of problems like this.
Well, yeah. That did not seem to bother anyone last spring, when we
Alvaro Herrera [EMAIL PROTECTED] writes:
What I want to know is how different from B+-trees are PostgreSQL
B-trees;
PG's btrees are in fact B+-trees according to the more formal
academic notation. IIRC the + just indicates allowing any number
of keys/downlinks in an internal tree node.
I've
Hi everyone,
An interesting development.
Afilias and LibertyRMS, the people who've been happily running the .info
namespace on PostgreSQL servers, are the technical backend of the ISOC
application for management of the .org
namespace. However, ICANN is asking for more detail about the backend
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] escribió:
Actually, there might not be a problem. c1.name can't be deleted until
both p1.name and p2.name go away, and at that point we want both c1.name
and gc1.name to go away. So as long as we don't *recursively*
48 matches
Mail list logo
