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
Attachments:
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