RE : full featured alter table?
Hello,
why not just order the output columns in alphabetical order?
This is quite easy to implement and requires no additional
storage. The output would be the same all the time and with all tools.
No, what we are talking about is to have the possibility to choose the
output order of the columns of a table (by adding a field in the
pg_attribute table).
I don't like GUI applications that creates their own tables in my schema
to store ordering or displaying informations. All the GUI that can
manages PostgreSQL database could use the pg_attribute table to store
the output order of the columns of the table.
I think that displays the output columns in alphabetical order will not
bring anything interesting... But if the pg_attributes table can be
enhanced to store order output, you could have the possibility to sort
yourself the ouput order. (Logical order, alphabetical order, or another
order...). The pg_attributes table would store (as I imagine) the
ordering number of each column.
People again should be warned to use select *
in applications, but this is another thing...
I agree with you, SELECT * must be avoided as much as possible.
Regards,
---------------------------------------
Bruno BAGUETTE - pgsql-ml@baguette.net
Import Notes
Reply to msg id not found: 3EECF694.4070206@wildenhain.de
Hi,
Bruno BAGUETTE wrote:
Hello,
why not just order the output columns in alphabetical order?
This is quite easy to implement and requires no additional
storage. The output would be the same all the time and with all tools.No, what we are talking about is to have the possibility to choose the
output order of the columns of a table (by adding a field in the
pg_attribute table).
Sure, I did understand that. But I think it is quite pointless
to burden the db or the app with such functionality.
Just to have random ordered columns which do not correspondent
to any physical ordering by the db.
So it does not influence query performance to arrange the
selected columns this or that order. So why confusing
the user by pretending it has any meaning to order the columns?
I think there are quite more praxis relevant problems to solve :)
Regards
Tino
On Mon, Jun 16, 2003 at 09:26:12PM +0200, Tino Wildenhain wrote:
<snip>
I think there are quite more praxis relevant problems to solve :)
ACK.
I'd like to see some features, which can be good for distributed databases:
* user defined OID spaces for serveral classes (and their derived classes)
* automatic mtime field update (but only if data really changed)
At the moment i'm doing this in the application (some not-too-small
php code), but it would be nice if the RDBMS could do this, so this
functionality could be provided directly through an SQL interface.
For many applications i use an object-like table model: each table
is derived from _inode, which defines an (cluster wiede) unique inode_id
and an mtime field. The applications do not make direct queries, but
access the db over an abstraction layer instead. This layer has definitions
for each class (object type, properties, etc) and generates queries for
actions like create, update, query, get,... It also implements some
little caching. On create() the abstraction layer generates an query which
fetches the inode_id from an sequence (this sequence has to be adjusted
for each node in the cluster, so each node has its own inode_id space)
and sets the mtime to current_timestamp(). On update() it also updates
the mtime field. But also there's an raw-store mode, which does _not_
update the mtime field, but writes it as it comes from the user
(this is necessary for syncing to avoid loops, since the post-out
uses the mtime to find out which records to send to another node)
I've tried to achieve this w/ rules, but i couldnt handle this
(perhaps i'm too stupid ? ;-))
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux ITS
Webhosting ab 5 EUR/Monat. UUCP, rawIP und vieles mehr.
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481 smsgate: sms.weigelt@metux.de
---------------------------------------------------------------------
Diese Mail wurde mit UUCP versandt. http://www.metux.de/uucp/
I think there are quite more praxis relevant problems to solve :)
ACK.
i cannot agree because there are always more important problems than others.
a mercedes is not such a beautiful car because of it's motor, but
because of the beautiful well thought out features in the cockpit. Of
course it would be a crappy car without a good motor - i hope you see,
that details matter as much as the big problems.