Обсуждение: pgsql-server/src/bin/psql print.c
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl@postgresql.org 02/11/01 10:12:19
Modified files:
src/bin/psql : print.c
Log message:
Avoid malloc(0) when printing a table of no columns. On some platforms
this returns NULL, which confuses the code.
Out of interest, how does one get a table of no columns? Chris On Fri, 1 Nov 2002, Tom Lane wrote: > CVSROOT: /cvsroot > Module name: pgsql-server > Changes by: tgl@postgresql.org 02/11/01 10:12:19 > > Modified files: > src/bin/psql : print.c > > Log message: > Avoid malloc(0) when printing a table of no columns. On some platforms > this returns NULL, which confuses the code. > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
On Sun, 2002-11-03 at 06:37, Christopher Kings-Lynne wrote: > Out of interest, how does one get a table of no columns? ALTER TABLE DROP COLUMN :) > On Fri, 1 Nov 2002, Tom Lane wrote: > > > CVSROOT: /cvsroot > > Module name: pgsql-server > > Changes by: tgl@postgresql.org 02/11/01 10:12:19 > > > > Modified files: > > src/bin/psql : print.c > > > > Log message: > > Avoid malloc(0) when printing a table of no columns. On some platforms > > this returns NULL, which confuses the code. > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Rod Taylor
Nup - DROP COLUMN (well at least the code I wrote) deliberately prevents you from doing that! Chris > -----Original Message----- > From: Rod Taylor [mailto:rbt@rbt.ca] > Sent: Sunday, 3 November 2002 10:49 PM > To: Christopher Kings-Lynne > Cc: Tom Lane; pgsql-committers@postgresql.org > Subject: Re: [COMMITTERS] pgsql-server/src/bin/psql print.c > > > On Sun, 2002-11-03 at 06:37, Christopher Kings-Lynne wrote: > > Out of interest, how does one get a table of no columns? > > ALTER TABLE DROP COLUMN :) > > > On Fri, 1 Nov 2002, Tom Lane wrote: > > > > > CVSROOT: /cvsroot > > > Module name: pgsql-server > > > Changes by: tgl@postgresql.org 02/11/01 10:12:19 > > > > > > Modified files: > > > src/bin/psql : print.c > > > > > > Log message: > > > Avoid malloc(0) when printing a table of no columns. On > some platforms > > > this returns NULL, which confuses the code. > > > > > > > > > ---------------------------(end of > broadcast)--------------------------- > > > TIP 5: Have you checked our extensive FAQ? > > > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > -- > Rod Taylor >
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Nup - DROP COLUMN (well at least the code I wrote) deliberately prevents you
> from doing that!
Yeah, but we ripped it out later, per this CVS log entry:
2002-09-28 16:00 tgl
* src/: backend/access/common/tupdesc.c,
backend/commands/tablecmds.c, backend/executor/execTuples.c,
backend/executor/nodeAgg.c, backend/parser/parse_target.c,
test/regress/expected/alter_table.out (REL7_3_STABLE),
backend/access/common/tupdesc.c, backend/commands/tablecmds.c,
backend/executor/execTuples.c, backend/executor/nodeAgg.c,
backend/parser/parse_target.c,
test/regress/expected/alter_table.out: Make the world at least
somewhat safe for zero-column tables, and remove the special case
in ALTER DROP COLUMN to prohibit dropping a table's last column.
I forget the details of the discussion leading up to that, but we
decided that prohibiting a DROP of a table's last column was creating
so much ugliness that we should try to remove the restriction; and upon
looking into it, there weren't *that* many places that would choke on
it. So as of the last month or so, you can do it. I would not be
surprised to find one or two more lurking problems with zero-column
tables, but I'd rather fix those than have the weird special case.
regards, tom lane
Ah ok - so it's something that went in while I wasn't subscribed. Do you now allow this as well? CREATE TABLE test (); Chris > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Monday, 4 November 2002 10:04 AM > To: Christopher Kings-Lynne > Cc: Rod Taylor; pgsql-committers@postgresql.org > Subject: Re: [COMMITTERS] pgsql-server/src/bin/psql print.c > > > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > Nup - DROP COLUMN (well at least the code I wrote) deliberately > prevents you > > from doing that! > > Yeah, but we ripped it out later, per this CVS log entry: > > 2002-09-28 16:00 tgl > > * src/: backend/access/common/tupdesc.c, > backend/commands/tablecmds.c, backend/executor/execTuples.c, > backend/executor/nodeAgg.c, backend/parser/parse_target.c, > test/regress/expected/alter_table.out (REL7_3_STABLE), > backend/access/common/tupdesc.c, backend/commands/tablecmds.c, > backend/executor/execTuples.c, backend/executor/nodeAgg.c, > backend/parser/parse_target.c, > test/regress/expected/alter_table.out: Make the world at least > somewhat safe for zero-column tables, and remove the special case > in ALTER DROP COLUMN to prohibit dropping a table's last column. > > I forget the details of the discussion leading up to that, but we > decided that prohibiting a DROP of a table's last column was creating > so much ugliness that we should try to remove the restriction; and upon > looking into it, there weren't *that* many places that would choke on > it. So as of the last month or so, you can do it. I would not be > surprised to find one or two more lurking problems with zero-column > tables, but I'd rather fix those than have the weird special case. > > regards, tom lane >
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Ah ok - so it's something that went in while I wasn't subscribed. Do you
> now allow this as well?
> CREATE TABLE test ();
No. In theory we could, but I'm not seeing the point; do you have an
example where this would be useful?
regards, tom lane
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > Ah ok - so it's something that went in while I wasn't > subscribed. Do you > > now allow this as well? > > > CREATE TABLE test (); > > No. In theory we could, but I'm not seeing the point; do you have an > example where this would be useful? Not in the slightest - it'd just be consistent ;) I don't advocate implementing it either! Chris