| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Some notes about Param handling with "Oracle style" plpgsql variables |
| Date: | 2009-11-02 19:18:14 |
| Message-ID: | 162867790911021118j143736f5rb84100fd18205bb3@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2009/11/2 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2009/11/2 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> This kinda calls into question whether the Oracle way is actually
>>> a good idea or not; but my purpose here is not to debate that,
>>> just to look at what it takes to implement it.
>
>> This is reason, why I would to see third mode (incompatible with
>> Oracle or pg), that raise error, when it detects any intersecting
>> identifiers. I understand so this mode should not be default, but
>> personally I'll use it everywhere.
>
> Actually, I thought we'd decided that "throw error on conflict"
> *would* be the default behavior.
good
regards
Pavel
>
> regards, tom lane
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-11-02 19:43:41 | Re: Renaming conversion procs (was Re: Error on compile for Windows) |
| Previous Message | Tom Lane | 2009-11-02 19:16:15 | Re: Some notes about Param handling with "Oracle style" plpgsql variables |