On 2010-11-24, Daniel Verite 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
>> 2 |
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 t
Stuart McGraw 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 notion of column
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 orde
On Wed, Nov 24, 2010 at 4:43 AM, 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 retu
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
On 11/24/2010 12:31 PM, Florian Weimer wrote:
* Grzegorz Jaśkiewicz:
2010/11/24 Florian Weimer:
* 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
* Grzegorz Jaśkiewicz:
> 2010/11/24 Florian Weimer :
>> * 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
>>>
2010/11/24 Florian Weimer :
> * 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
* 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 fea
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 in
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
you
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
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
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
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
> Hey Alexander,
>
> Ordinal positions of columns can't be set manually by ALTER TABLE.
>
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 y
Easier to read... login, logout
On Wed, Nov 24, 2010 at 8:45 AM, Szymon Guz 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:
http://www.postgresql.org/mailpref/pgsql-genera
Hey Alexander,
Ordinal positions of columns can't be set manually by ALTER TABLE.
2010/11/24 Alexander Farber
> 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 ri
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 (p
On 24 November 2010 08:42, Alexander Farber wrote:
> 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;
>Tab
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 |
22 matches
Mail list logo
