Hi Alex,
On Sun, Mar 30, 2008 at 7:10 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> (trimmed cc's)
>
> Find attached inherited_constraint_v2.patch
>
> Changes since v1:
> -rebased against latest HEAD
> -changed enum { Anum_pg_constraint_... } back into #define
> Anum_pg_constraint_...
> -remove
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Hmm. Personally, most of my uses of \df are for the purpose of looking
> for built-in functions, and so this'd be a step backwards for my usage.
> Likewise for operators. Maybe I'm in the minority or maybe not.
> The only one of these things for which the
On 31/03/2008, Gregory Stark <[EMAIL PROTECTED]> wrote:
> It might be cute to see if the pattern matches any user functions and if not
> try again with system functions. So you would still get results if you did
> "\df rtrim" for example.
>
Nice idea. +1 for this behaviour.
Cheers,
BJ
--
Se
Hi,
I tried to split the previous patch up to see where the tsearch regression
comes from. So, it turned out that:
- float4 conversion is risk free (patch #1)
- float8 conversion is okay, too, if coupled with time[stamp[tz]] conversion
(patch #2) but with int64 timestamps enabled, the next on
Gregory Stark <[EMAIL PROTECTED]> writes:
> It might be cute to see if the pattern matches any user functions and if not
> try again with system functions. So you would still get results if you did
> "\df rtrim" for example.
Interesting idea. IIUC, \df would give you either all user functions
*o
On 01/04/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> ... That means
> there'd be no way to replicate the all-functions-of-both-types behavior
> that has been the default in every prior release.
> \dfS-> sys functions only
> \dfU-> user functions only
> \dfSU ->
correct queue
Hello
I finished this patch.
Proposal: http://archives.postgresql.org/pgsql-hackers/2008-01/msg00696.php
It's compatible with PL/SQL (Oracle) and SQL/PSM (ANSI).
CASE statements is parsed and transformed to CASE expression and
statements paths. Result of CASE expression is u
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> It might be cute to see if the pattern matches any user functions and if not
>> try again with system functions. So you would still get results if you did
>> "\df rtrim" for example.
>
> Interesting idea. IIUC,
Gregory Stark <[EMAIL PROTECTED]> writes:
> One --perhaps nice, perhaps not-- property of this is that if you defined a
> function named "rtrim" and then did "\df rtrim" it would show you _both_ the
> system and user function and make it easier to see the conflict. Whereas the
> other behaviour I p
Pavel Stehule wrote:
correct queue
Hello
I finished this patch.
Proposal: http://archives.postgresql.org/pgsql-hackers/2008-01/msg00696.php
It's compatible with PL/SQL (Oracle) and SQL/PSM (ANSI).
At the very least this patch is missing documentation and regression tests.
cheers
Hello
On 31/03/2008, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> Pavel Stehule wrote:
>
> > correct queue
> >
> > Hello
> >
> > I finished this patch.
> >
> > Proposal:
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00696.php
> >
> > It's compatible with PL/SQL (Oracle) and SQL/
Gregory Stark wrote:
Here's the WIP patch I described on -hackers to implemented "ordered" append
nodes.
I think it would be better to create completely separate executor node
for this, rather than tack this feature on the regular Append node. The
two don't seem to have much in common. Lookin
Tom Lane wrote:
> BTW, should we remove the special hack that discriminates against
> showing I/O functions (or really anything that touches cstring) in \df?
> ISTM that was mostly there to reduce clutter, and this proposal solves
> that problem more neatly. I know I've cursed that behavior under
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> One --perhaps nice, perhaps not-- property of this is that if you defined a
>> function named "rtrim" and then did "\df rtrim" it would show you _both_ the
>> system and user function and make it easier to see th
On Mon, Mar 31, 2008 at 2:36 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> Hi Alex,
> I was taking a look at this patch to add the pg_dump related changes. Just
> wanted to give you a heads up as this patch crashes if we run "make
> installcheck". Seems there is an issue introduced in the CREATE TABLE
Gregory Stark <[EMAIL PROTECTED]> writes:
>>> One --perhaps nice, perhaps not-- property of this is that if you defined a
>>> function named "rtrim" and then did "\df rtrim" it would show you _both_ the
>>> system and user function and make it easier to see the conflict. Whereas the
>>> other behav
16 matches
Mail list logo
