pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
Problem about pgsql's column alias
11+ messages / 4 participants
[nested] [flat]

* Problem about pgsql's column alias
@ 2003-04-14 05:16  milimeter@163.com <milimeter@163.com>
  0 siblings, 1 reply; 11+ messages in thread

From: milimeter@163.com @ 2003-04-14 05:16 UTC (permalink / raw)
  To: pgsql-general@postgresql.org

Hello, everybody

  I found that in postgresql, we can only use "select login_name as name from 
users;" to get an alias "name" for column "login_name", but in most other 
databases we can omit the "as", that is "select login_name name from users;".

  Now I will convert a lot of program from oracle to postgresql, there're so 
many place to be correct from "AAA BBB" to "AAA as BBB", can anybody give me 
a good method to do that? Or, if the next version of postgresql will have the 
same feature as other databases?

  Thanks a lot,
  Yours,
  mili




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Problem about pgsql's column alias
@ 2003-04-14 05:44  Tom Lane <tgl@sss.pgh.pa.us>
  parent: milimeter@163.com <milimeter@163.com>
  0 siblings, 1 reply; 11+ messages in thread

From: Tom Lane @ 2003-04-14 05:44 UTC (permalink / raw)
  To: milimeter@163.com; +Cc: pgsql-general@postgresql.org

"milimeter@163.com" <milimeter@163.com> writes:
>   I found that in postgresql, we can only use "select login_name as name from 
> users;" to get an alias "name" for column "login_name", but in most other 
> databases we can omit the "as", that is "select login_name name from users;".

AS is not optional in Postgres, and will never be so unless we choose to
drop support for postfix operators, which I consider an unlikely choice.
Example: in
		SELECT foo ! bar;
is the "!" an infix operator, or is it postfix with the intended meaning
		SELECT (foo!) AS bar;

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: [GENERAL] Problem about pgsql's column alias
@ 2003-04-14 16:40  Peter Eisentraut <peter_e@gmx.net>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 11+ messages in thread

From: Peter Eisentraut @ 2003-04-14 16:40 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: milimeter@163.com, PostgreSQL Development <pgsql-hackers@postgresql.org>

Tom Lane writes:

> AS is not optional in Postgres, and will never be so unless we choose to
> drop support for postfix operators, which I consider an unlikely choice.

Well, we could drop the support for postfix operators in aliasing clauses
that omit the AS.  In fact, I got the following to work with no further
changes:

target_el: a_expr AS ColLabel
           | c_expr IDENT  // new
           | a_expr
           | '*'

If we wanted more than IDENT, we would need to trade off some key words in
(few) other places, but it looks doable.

-- 
Peter Eisentraut   peter_e@gmx.net




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: [GENERAL] Problem about pgsql's column alias
@ 2003-04-14 17:00  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Peter Eisentraut <peter_e@gmx.net>
  0 siblings, 2 replies; 11+ messages in thread

From: Tom Lane @ 2003-04-14 17:00 UTC (permalink / raw)
  To: Peter Eisentraut <peter_e@gmx.net>; +Cc: milimeter@163.com, PostgreSQL Development <pgsql-hackers@postgresql.org>

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> AS is not optional in Postgres, and will never be so unless we choose to
>> drop support for postfix operators, which I consider an unlikely choice.

> Well, we could drop the support for postfix operators in aliasing clauses
> that omit the AS.

I think it would be a bad idea in any case; it would mask errors too
easily.  For example, you meant to say "SELECT a + b, ..." but wrote
"SELECT a b, ...".  Or how about this:
	SELECT 'foo'::character varying
Is "varying" an alias or part of the type name?

We've recently seen at least one comparable case where someone
unintentionally wrote what looked to the parser like a FROM-clause
alias, and was mystified at the behavior (I forget the details, but it
was just a week or two back).  Omitting AS in FROM-clauses is tolerable
because the possible syntax in that area is fairly restricted, but I
think the spec authors were just plain foolish to allow it in the SELECT
targetlist.

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: [GENERAL] Problem about pgsql's column alias
@ 2003-04-15 00:35  Kevin Brown <kevin@sysexperts.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  1 sibling, 1 reply; 11+ messages in thread

From: Kevin Brown @ 2003-04-15 00:35 UTC (permalink / raw)
  To: PostgreSQL Development <pgsql-hackers@postgresql.org>

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane writes:
> >> AS is not optional in Postgres, and will never be so unless we choose to
> >> drop support for postfix operators, which I consider an unlikely choice.
> 
> > Well, we could drop the support for postfix operators in aliasing clauses
> > that omit the AS.
> 
> I think it would be a bad idea in any case; it would mask errors too
> easily.  For example, you meant to say "SELECT a + b, ..." but wrote
> "SELECT a b, ...".  Or how about this:
> 	SELECT 'foo'::character varying
> Is "varying" an alias or part of the type name?

Shouldn't we be deprecating the use of :: in favor of the SQL-standard
CAST()?


-- 
Kevin Brown					      kevin@sysexperts.com




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: [GENERAL] Problem about pgsql's column alias
@ 2003-04-15 05:49  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Kevin Brown <kevin@sysexperts.com>
  0 siblings, 0 replies; 11+ messages in thread

From: Tom Lane @ 2003-04-15 05:49 UTC (permalink / raw)
  To: Kevin Brown <kevin@sysexperts.com>; +Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>

Kevin Brown <kevin@sysexperts.com> writes:
> Shouldn't we be deprecating the use of :: in favor of the SQL-standard
> CAST()?

Deprecate it all you like ... but I have no intention of giving up a
two-keystroke notation for a ten-keystroke one ...

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: [GENERAL] Problem about pgsql's column alias
@ 2003-04-15 13:24  Peter Eisentraut <peter_e@gmx.net>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  1 sibling, 1 reply; 11+ messages in thread

From: Peter Eisentraut @ 2003-04-15 13:24 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: milimeter@163.com, PostgreSQL Development <pgsql-hackers@postgresql.org>

Tom Lane writes:

> I think it would be a bad idea in any case; it would mask errors too
> easily.  For example, you meant to say "SELECT a + b, ..." but wrote
> "SELECT a b, ...".  Or how about this:
> 	SELECT 'foo'::character varying
> Is "varying" an alias or part of the type name?

That seems like a rather poor excuse for not supporting a standard feature
that people seem to ask about every week.  If someone can't tell the
difference between a and a + b he's going to have more problems than this.

-- 
Peter Eisentraut   peter_e@gmx.net




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: [GENERAL] Problem about pgsql's column alias
@ 2003-04-15 14:17  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Peter Eisentraut <peter_e@gmx.net>
  0 siblings, 1 reply; 11+ messages in thread

From: Tom Lane @ 2003-04-15 14:17 UTC (permalink / raw)
  To: Peter Eisentraut <peter_e@gmx.net>; +Cc: milimeter@163.com, PostgreSQL Development <pgsql-hackers@postgresql.org>

Peter Eisentraut <peter_e@gmx.net> writes:
> That seems like a rather poor excuse for not supporting a standard feature
> that people seem to ask about every week.

Actually, that was the first complaint that I can recall hearing in
quite some time.

I think this is simply a place where the spec got it wrong, and we
should agree to disagree, as we have done with identifier case-folding
for example ...

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: [GENERAL] Problem about pgsql's column alias
@ 2003-04-16 13:46  Peter Eisentraut <peter_e@gmx.net>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 11+ messages in thread

From: Peter Eisentraut @ 2003-04-16 13:46 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: milimeter@163.com, PostgreSQL Development <pgsql-hackers@postgresql.org>

Tom Lane writes:

> I think this is simply a place where the spec got it wrong, and we
> should agree to disagree, as we have done with identifier case-folding
> for example ...

That is not at all the same situation.  The identifier-case folding goes
back to an unconscious design decision years ago and changing it now would
break everything.  Allowing column aliases without AS would break nothing.

-- 
Peter Eisentraut   peter_e@gmx.net




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: [GENERAL] Problem about pgsql's column alias
@ 2003-04-16 14:16  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Peter Eisentraut <peter_e@gmx.net>
  0 siblings, 1 reply; 11+ messages in thread

From: Tom Lane @ 2003-04-16 14:16 UTC (permalink / raw)
  To: Peter Eisentraut <peter_e@gmx.net>; +Cc: milimeter@163.com, PostgreSQL Development <pgsql-hackers@postgresql.org>

Peter Eisentraut <peter_e@gmx.net> writes:
> Allowing column aliases without AS would break nothing.

... except postfix operators, and whatever else happens to get caught in
the crossfire.  And we'll still get complaints because it only works for
identifiers, not for keywords.

Now I'll admit that the postfix-operator issue is probably a red
herring, since "SELECT a + b, ..." should get interpreted as infix +
in any case.  But I think there are other side-effects we have not
fully analyzed yet.  The one-line grammar hack was not intended to
be actually applied, right?  Let's see a complete proposal.

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: [GENERAL] Problem about pgsql's column alias
@ 2003-05-15 20:04  Peter Eisentraut <peter_e@gmx.net>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 11+ messages in thread

From: Peter Eisentraut @ 2003-05-15 20:04 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>

Tom Lane writes:

> > Allowing column aliases without AS would break nothing.
>
> Now I'll admit that the postfix-operator issue is probably a red
> herring, since "SELECT a + b, ..." should get interpreted as infix +
> in any case.  But I think there are other side-effects we have not
> fully analyzed yet.  The one-line grammar hack was not intended to
> be actually applied, right?  Let's see a complete proposal.

I have analyzed the all the grammar conflicts that the optional AS would
cause.  The real killer were these two clauses:

expr ISNULL
expr NOTNULL

I don't know how to resolve that without making ISNULL and NOTNULL more
reserved than any other word, which seems unattractive.

(The only two other areas of conflict where postfix operators and trailing
multiword type names in ::-style type casts, which we already talked
about.)

-- 
Peter Eisentraut   peter_e@gmx.net




^ permalink  raw  reply  [nested|flat] 11+ messages in thread


end of thread, other threads:[~2003-05-15 20:04 UTC | newest]

Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-04-14 05:16 Problem about pgsql's column alias milimeter@163.com <milimeter@163.com>
2003-04-14 05:44 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-04-14 16:40   ` Peter Eisentraut <peter_e@gmx.net>
2003-04-14 17:00     ` Tom Lane <tgl@sss.pgh.pa.us>
2003-04-15 00:35       ` Kevin Brown <kevin@sysexperts.com>
2003-04-15 05:49         ` Tom Lane <tgl@sss.pgh.pa.us>
2003-04-15 13:24       ` Peter Eisentraut <peter_e@gmx.net>
2003-04-15 14:17         ` Tom Lane <tgl@sss.pgh.pa.us>
2003-04-16 13:46           ` Peter Eisentraut <peter_e@gmx.net>
2003-04-16 14:16             ` Tom Lane <tgl@sss.pgh.pa.us>
2003-05-15 20:04               ` Peter Eisentraut <peter_e@gmx.net>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox