On 2010-11-24, Daniel Verite dan...@manitou-mail.org wrote:
Fredric Fredricson wrote:
But if you change the column names in the second SELECT in the UNION this is
ignored:
# SELECT c1,c2 FROM (SELECT 1 AS c1, 2 AS c2 UNION SELECT 2 AS c3, 1 AS c4)
AS x;
c1 | c2
+
1 | 2
Alexander Farber, 24.11.2010 08:49:
Why do you want to do anything like that?
Easier to read... login, logout
I understand the easier to read part.
But what do you mean with login, logout?
Thomas
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
Please note, that in cases when you can't do simple
dump - fix - restore (e.g. in production) you can always create
view(s) with ordinal positions of columns convenient for you.
2010/11/24 Dmitriy Igrishin dmit...@gmail.com
Hey Alexander,
Ordinal positions of columns can't be set manually by
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in some other.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
Grzegorz Jaśkiewicz, 24.11.2010 10:37:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in some other.
I always try to convince people
On Wed, Nov 24, 2010 at 09:37:02AM +, Grzegorz Jaśkiewicz wrote:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in some other.
It is easy to create view based on SELECT which explicitly specifies
the columns names. IMO it is better to hide tables structures behind views
and work with them, since views are not materialized and it is easy to drop
and recreate or just add another view into the database. With this approach
On 2010-11-24 10.43, Thomas Kellerer wrote:
Grzegorz Jaśkiewicz, 24.11.2010 10:37:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be
* Grzegorz Jaśkiewicz:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in some other.
This can't be true because several SQL
2010/11/24 Florian Weimer fwei...@bfk.de:
* Grzegorz Jaśkiewicz:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in some other.
* Grzegorz Jaśkiewicz:
2010/11/24 Florian Weimer fwei...@bfk.de:
* Grzegorz Jaśkiewicz:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
On 11/24/2010 12:31 PM, Florian Weimer wrote:
* Grzegorz Jaśkiewicz:
2010/11/24 Florian Weimerfwei...@bfk.de:
* Grzegorz Jaśkiewicz:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table
Fredric Fredricson wrote:
But if you change the column names in the second SELECT in the UNION this is
ignored:
# SELECT c1,c2 FROM (SELECT 1 AS c1, 2 AS c2 UNION SELECT 2 AS c3, 1 AS c4)
AS x;
c1 | c2
+
1 | 2
2 | 1
Apparently, in a UNION the column names are
On Wed, Nov 24, 2010 at 4:43 AM, Thomas Kellerer spam_ea...@gmx.net wrote:
Grzegorz Jaśkiewicz, 24.11.2010 10:37:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one
On 11/24/2010 03:32 AM, Peter Bex wrote:
On Wed, Nov 24, 2010 at 09:37:02AM +, Grzegorz Jaśkiewicz wrote:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the
Stuart McGraw smcg2...@frii.com writes:
This is the first time I've ever looked at the 1000+ page spec and I
haven't tried to chase down all the definitions so I don't pretend to
be authoritative but it sure sounds to me (as your observation above
implies) that SQL *does* have an explicit
On Nov 24, 2010, at 9:42 AM, Derrick Rice wrote:
Even if an example doesn't exist, you can at least imagine a scenario where
an improvement to postgresql is made such that the column order is decided
internally, rather than by table definition.
Not when SQL compatibility requires that the
Hello,
is there a syntax to add a column not at the last place, but
somewhere inbetween or do I have to dump/restore the table?
For example if I'd like to add last_logout right after last_login:
\d pref_users;
Table public.pref_users
Column |Type |
On 24 November 2010 08:42, Alexander Farber alexander.far...@gmail.comwrote:
Hello,
is there a syntax to add a column not at the last place, but
somewhere inbetween or do I have to dump/restore the table?
For example if I'd like to add last_logout right after last_login:
\d pref_users;
Alexander Farber, 24.11.2010 08:42:
is there a syntax to add a column not at the last place
No, because the order of the column is irrelevant (just as there is no order on
the rows in a table)
Simply select them in the order you like to have.
Thomas
--
Sent via pgsql-general mailing list
Hey Alexander,
Ordinal positions of columns can't be set manually by ALTER TABLE.
2010/11/24 Alexander Farber alexander.far...@gmail.com
Hello,
is there a syntax to add a column not at the last place, but
somewhere inbetween or do I have to dump/restore the table?
For example if I'd like
Easier to read... login, logout
On Wed, Nov 24, 2010 at 8:45 AM, Szymon Guz mabew...@gmail.com wrote:
no
Why do you want to do anything like that?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
22 matches
Mail list logo