Marc Lavergne wrote:
> That's an quite a bite to chew given my level of experience with
> PostgreSQL internals! However, I will keep it in mind and whatever I do
> will be fully abstracted (already is actually) so that it should just a
> matter of snapping it into place when 7.4 forks. Realisti
> > The nice part is it has an varying number of arguments, and can
> > used within "sort". Very useful sometimes.
>
> With our CASE, you create a column using the CASE, then ODER BY on that
> column.
Not exactly, you have to create a column for this, and it will be in the select list.
Oracle do
Mario Weilguni wrote:
> Yes this is completly different. Oracle decode works like this:
>
> decode(value, choice1, result1, choice 2, result2, ..,
> default_result)
>
> it works this way: case
> when value=choice1 then result1 when value=choice2 then result2
>
> else default_resu
> > feature of that type. But random misfeatures such as the join syntax or
> > the decode() function are going to have a hard time getting accepted.
>
> But we have decode():
>
> test=> \df decode
> List of functions
>Result data type | Schema | Nam
>> But we have decode():
It is a different decode function, more akin to "case when".
>> Just to give you a fair warning: I'm not going to be in favor of
adding any "Oracle compatibility" functionality that overlaps with
existing and/or standardized functionality.
I wouldn't even dream of
Peter Eisentraut wrote:
> Marc Lavergne writes:
>
> > This covers a few different sub-projects so I'm breaking it down in
> > order of how I'm going to attack it.
>
> Just to give you a fair warning: I'm not going to be in favor of adding
> any "Oracle compatibility" functionality that overlaps
Marc Lavergne writes:
> This covers a few different sub-projects so I'm breaking it down in
> order of how I'm going to attack it.
Just to give you a fair warning: I'm not going to be in favor of adding
any "Oracle compatibility" functionality that overlaps with existing
and/or standardized fun
That's an quite a bite to chew given my level of experience with
PostgreSQL internals! However, I will keep it in mind and whatever I do
will be fully abstracted (already is actually) so that it should just a
matter of snapping it into place when 7.4 forks. Realistically, I can't
comment from
Marc Lavergne <[EMAIL PROTECTED]> writes:
> PostgreSQL parse/bind/execute Layer:
>
> This would be mimicked since PostgreSQL doesn't support it
> natively.
What's stopping you from implementing native support for this? There
will hopefully be an FE/BE protocol
This covers a few different sub-projects so I'm breaking it down in
order of how I'm going to attack it. The TTC estimates are going to vary
based on my bandwidth which, unfortunately, is pretty tight right now.
However, there is relief on the horizon and I do have a vested interest
in getti
Marc, wher did we leave this? Also, 7.3 will have prepared statements
in the backend code, so that should make the porting job easier.
---
Marc Lavergne wrote:
> The code comes from a project in which I needed to import fr
The code comes from a project in which I needed to import from Oracle
export files into PostgreSQL. I determined the export file format and
created a parser class. Since the INSERT syntax in Oracle export files
is based on a parse/bind/execute model, I created second module which
implements a
Tom Lane wrote:
> Marc Lavergne <[EMAIL PROTECTED]> writes:
> > never any mention of C++ (libpq++ excepted). So, at a risk of stating
> > the obvious (and I'm 99.99% sure I am), does backend code need to be
> > submitted as C even if it's for an entirely NEW module?
>
> Backend code must be C;
Marc Lavergne <[EMAIL PROTECTED]> writes:
> never any mention of C++ (libpq++ excepted). So, at a risk of stating
> the obvious (and I'm 99.99% sure I am), does backend code need to be
> submitted as C even if it's for an entirely NEW module?
Backend code must be C; we do not want to deal with
I am working on a rather extensive Oracle compatibility layer that I use
with PostgreSQL. I am considering contributing the code back to the
project but the problem is that the layer is currently implemented in
C++. Simply looking throughout the sources and the dev FAQ, there's
never any menti
15 matches
Mail list logo
