Обсуждение: syntax extension for unsupported JOINs coming from a binary only (unmodifyable) program

Here are some little changes to the postgreSQL server backend I found
beeing convenient for me
while I was attempting to get interoparability with a binary only
program. The patch attached is tested and works
for 8.0.0beta3.
The so called big ones under these DBMS eat the following kind of join
without complaining:

select a.val1, b.val2, c.val3 from
    t1 a left outer join t2 b on (a.id1=b.id2),
    t1    left outer join t3 c on (a.id1=c.id3);

the content of the patch reorders the parse tree to get the same result
as this (working recursively for subselects etc.):

select a.val1, b.val2, c.val3 from
    t1 a left outer join t2 b on (a.id1=b.id2)
    left outer join t3 c on (a.id1=c.id3);

Wolfgang

Wolfgang <wh@ibas-labs.de> writes:
> Here are some little changes to the postgreSQL server backend I found 
> beeing convenient for me

You don't seriously expect any of this to get applied, do you?

nullstr0 reverts a deliberate change made in PG 7.3.  It's way past
time to be complaining about that.

LIKE_IS_ILIKE ... uh, well, no it isn't.  If you'd like it to be, a
better approach would be to define a case-insensitive datatype (see
for example citext on pgfoundry) or a case-insensitive locale.

The proposed join change is, so far as I can see, a serious breakage of
the SQL spec.  Perhaps you should fix the application to generate valid
SQL instead.  (Even if it were a reasonable thing to do, postgres.c is
not a reasonable place to do it.)


More generally, it's been quite some time since we've looked with
favor on feature changes enabled by #ifdefs.  Those aren't convenient
for anybody.

Lastly, diffs that are not -c or -u format will be rejected out of hand;
they are far too risky to apply to source code that is not exactly the
same version you started from.
        regards, tom lane