On 2017-02-24 07:25, Robert Haas wrote:
> I don't think it's only Oracle that allows omitting the
> alias; I think there are a number of other systems that behave
> similarly.
SQLite, for example.
Making conversions from SQLite to Postgres easier is a Good Thing.
"subquery in FROM must have an al
On Fri, Feb 24, 2017 at 9:35 AM, David Fetter wrote:
>
> > => SELECT "?column"? FROM (select 1+1 as "?column?", 1+1) AS x;
> > ERROR: 42703: column "?column" does not exist
> > LINE 2: SELECT "?column"? FROM (select 1+1 as "?column?", 1+1) AS x;
> >^
> > HINT: Perhaps you meant
On Thu, Feb 23, 2017 at 01:27:29PM +, Greg Stark wrote:
> On 22 February 2017 at 15:08, Tom Lane wrote:
> > Indeed. When I wrote the comment you're referring to, quite a few years
> > ago now, I thought that popular demand might force us to allow omitted
> > aliases. But the demand never mat
Craig Ringer writes:
> Personally I think we need to generate one, if nothing else for error
> messages where we try to emit qualified names of columns.
Also for EXPLAIN, where there has to be a way to name everything.
> But I don't see that the name needs to be anything we can refer to
> elsewh
On Fri, Feb 24, 2017 at 1:04 PM, Craig Ringer wrote:
> On 23 February 2017 at 22:20, Tom Lane wrote:
>>> * Don't force/generate an alias at all.
>>
>>> I've no idea for this yet and Tom already was concerned what this might
>>> break. There are several places in the transform phase where the
>>>
On 23 February 2017 at 22:20, Tom Lane wrote:
>> * Don't force/generate an alias at all.
>
>> I've no idea for this yet and Tom already was concerned what this might
>> break. There are several places in the transform phase where the
>> refnames are required (e.g. isLockedRefname()).
>
> Yeah. T
On Thu, Feb 23, 2017 at 4:08 PM, Pantelis Theodosiou wrote:
> Question: Will the patch be removed if and when Oracle decides to be
> compatible with the standard and forbids non-aliased derived tables?
>
> (I know it's a rather theoretical question. Unlikely that Oracle breaks
> backwards compatib
On Thu, Feb 23, 2017 at 7:50 PM, Tom Lane wrote:
> Maybe the best answer is to not do it immediately when transforming the
> subselect's RTE, but to go back after we've finished transforming the
> entire FROM clause and add aliases to any RTEs that lack them. I think
> probably at that point you
On Thu, Feb 23, 2017 at 10:37:16AM +0100, Bernd Helmle wrote:
> Am Mittwoch, den 22.02.2017, 22:17 -0500 schrieb Tom Lane:
> > [ shrug... ] Well, I won't resist this hard as long as it's done
> > competently, which to me means "the subquery name doesn't conflict
> > with
> > anything else". Not "
Bernd Helmle writes:
> Right, i'm going to give it a try then. Currently i see these options:
> * Validate any generated alias against a list of explicit alias names.
> This means we have to collect explicit alias names in, say a hashtable,
> and validate a generated name against potential colli
Greg Stark writes:
> On 22 February 2017 at 15:08, Tom Lane wrote:
>> Indeed. When I wrote the comment you're referring to, quite a few years
>> ago now, I thought that popular demand might force us to allow omitted
>> aliases. But the demand never materialized. At this point it seems
>> clear
On 23 February 2017 at 13:27, Greg Stark wrote:
> => SELECT "?column"? FROM (select 1+1 as "?column?", 1+1) AS x;
Oops, I missed the typo there:
=> SELECT "?column?" FROM (select 1+1 AS "?column?", 1+1) AS x;
ERROR: 42702: column reference "?column?" is ambiguous
LINE 2: SELECT "?column?" FROM
On 22 February 2017 at 15:08, Tom Lane wrote:
> Indeed. When I wrote the comment you're referring to, quite a few years
> ago now, I thought that popular demand might force us to allow omitted
> aliases. But the demand never materialized. At this point it seems
> clear to me that there isn't re
On Thu, Feb 23, 2017 at 3:17 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams
> wrote:
> >> I suspect most users, like me, just roll their eyes, grumble, and put up
> >> with it rather than complain. It's a pain point, but tolerable enough
> >> that
Am Mittwoch, den 22.02.2017, 22:17 -0500 schrieb Tom Lane:
> [ shrug... ] Well, I won't resist this hard as long as it's done
> competently, which to me means "the subquery name doesn't conflict
> with
> anything else". Not "it doesn't conflict unless you're unlucky
> enough
> to have used the sa
Robert Haas writes:
> On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams wrote:
>> I suspect most users, like me, just roll their eyes, grumble, and put up
>> with it rather than complain. It's a pain point, but tolerable enough
>> that no one bothers to demand a change. Now that it's been done th
On 2017-02-23 08:21:41 +0530, Robert Haas wrote:
> On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams wrote:
> > On Wed, Feb 22, 2017 at 10:08:38AM -0500, Tom Lane wrote:
> >> Bernd Helmle writes:
> >> >> From time to time, especially during migration projects from Oracle to
> >> > PostgreSQL, i'm f
On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams wrote:
> On Wed, Feb 22, 2017 at 10:08:38AM -0500, Tom Lane wrote:
>> Bernd Helmle writes:
>> >> From time to time, especially during migration projects from Oracle to
>> > PostgreSQL, i'm faced with people questioning why the alias in the FROM
>> >
On Wed, 2017-02-22 at 08:13 -0700, David G. Johnston wrote:
> I'll contribute to the popular demand aspect but given that the error
> is
> good and the fix is very simple its not exactly a strong desire.
In one project i've recently seen, for some reasons, they need to
maintain an application twic
On Wed, Feb 22, 2017 at 10:08:38AM -0500, Tom Lane wrote:
> Bernd Helmle writes:
> >> From time to time, especially during migration projects from Oracle to
> > PostgreSQL, i'm faced with people questioning why the alias in the FROM
> > clause for subqueries in PostgreSQL is mandatory. The default
On Wed, 2017-02-22 at 10:08 -0500, Tom Lane wrote:
>
> Indeed. When I wrote the comment you're referring to, quite a few
> years
> ago now, I thought that popular demand might force us to allow
> omitted
> aliases. But the demand never materialized. At this point it seems
> clear to me that the
On Wed, Feb 22, 2017 at 8:08 AM, Tom Lane wrote:
> Or else not generate
> a name at all, in which case there simply wouldn't be a way to refer to
> the subquery by name; I'm not sure what that might break though.
>
Yeah, usually when I want this I don't end up needing refer by name:
First I wr
On Wed, Feb 22, 2017 at 8:08 AM, Tom Lane wrote:
> Bernd Helmle writes:
> >> From time to time, especially during migration projects from Oracle to
> > PostgreSQL, i'm faced with people questioning why the alias in the FROM
> > clause for subqueries in PostgreSQL is mandatory. The default answer
Bernd Helmle writes:
>> From time to time, especially during migration projects from Oracle to
> PostgreSQL, i'm faced with people questioning why the alias in the FROM
> clause for subqueries in PostgreSQL is mandatory. The default answer
> here is, the SQL standard requires it.
Indeed. When I
>From time to time, especially during migration projects from Oracle to
PostgreSQL, i'm faced with people questioning why the alias in the FROM
clause for subqueries in PostgreSQL is mandatory. The default answer
here is, the SQL standard requires it.
This also is exactly the comment in our parser
25 matches
Mail list logo