2009/4/11 David Fetter :
> On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
>> Yeah, but all the window functions are stored in pg_proc.
>
> So are aggregate functions, and they have their own separate way of
> being addressed in psql :)
>
Aggregate functions are stored in pg_aggreg
On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
2009/4/11 David Fetter :
On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
Yeah, but all the window functions are stored in pg_proc.
So are aggregate functions, and they have their own separate way of
being addressed in psql :)
Jaime Casanova wrote:
> On Fri, Apr 10, 2009 at 11:47 PM, Abhijit Menon-Sen wrote:
> > Hi.
> >
> > There's a TODO item about making COMMENT ON accept an expression.
>
> really? what's the use case for that?
I assume it is for creating comments using things like || or maybe
CURRENT_TIMESTAMP:
2009/4/11 Grzegorz Jaskiewicz :
>
> On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
>
>> 2009/4/11 David Fetter :
>>>
>>> On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
Yeah, but all the window functions are stored in pg_proc.
>>>
>>> So are aggregate functions, and they
On 11 Apr 2009, at 13:33, Hitoshi Harada wrote:
Maybe trigger functions should be displayed separately too than ?
You don't catch the point. The aggregate entries in pg_proc have
prosrc = 'aggregate_dummy', which means they're dummy and the entities
are stored in pg_aggregate. Triggers in pg_
On Sat, Apr 11, 2009 at 5:06 AM, Grzegorz Jaskiewicz
wrote:
> On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
>> 2009/4/11 David Fetter :
>>> On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
Yeah, but all the window functions are stored in pg_proc.
>>> So are aggregate function
On Sat, Apr 11, 2009 at 01:39:47PM +0100, Grzegorz Jaskiewicz wrote:
>
> On 11 Apr 2009, at 13:33, Hitoshi Harada wrote:
>
>>> Maybe trigger functions should be displayed separately too than ?
>>
>> You don't catch the point. The aggregate entries in pg_proc have
>> prosrc = 'aggregate_dummy', whic
On Sat, Apr 11, 2009 at 08:52:31AM -0400, Robert Haas wrote:
> On Sat, Apr 11, 2009 at 5:06 AM, Grzegorz Jaskiewicz
> wrote:
> > On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
> >> 2009/4/11 David Fetter :
> >>> On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
> Yeah, but all
2009/4/11 Grzegorz Jaskiewicz :
>
> On 11 Apr 2009, at 13:33, Hitoshi Harada wrote:
>
>>> Maybe trigger functions should be displayed separately too than ?
>>
>> You don't catch the point. The aggregate entries in pg_proc have
>> prosrc = 'aggregate_dummy', which means they're dummy and the entitie
Abhijit Menon-Sen writes:
> There's a TODO item about making COMMENT ON accept an expression. The
> grammar change is simple (SConst|NULL_P->a_expr), but as far as I can
> see, there are no similar utility commands that take expressions, and
> I'm not very familiar with the planner and executor, s
A thread over in -admin has made me realize the truth of $SUBJECT.
With --clean, pg_dumpall does indeed emit a DROP command for each
role, tablespace, or database ... just before recreating it. This
takes no account of dependencies and so the role and tablespace
drops are pretty much guaranteed to
David Fetter writes:
> On Sat, Apr 11, 2009 at 08:52:31AM -0400, Robert Haas wrote:
>> We're up to at least four different categories of functions that
>> people think might require special treatment: window, trigger, I/O,
>> everything else.
> The current psql has \da and \df, the latter of whic
On Sat, Apr 11, 2009 at 10:32:14AM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Sat, Apr 11, 2009 at 08:52:31AM -0400, Robert Haas wrote:
> >> We're up to at least four different categories of functions that
> >> people think might require special treatment: window, trigger,
> >> I/O, ever
David Fetter writes:
> The "do nothing" solution is unacceptable because windowing functions
> behave in a way that's essentially different, from the user's
> perspective, from other functions including aggregates.
I don't like doing nothing either, but I disagree with your conclusion
that window
On Fri, Apr 10, 2009 at 05:54:25PM -0400, Tom Lane wrote:
> It gets worse though: I have seldom seen such a badly designed piece of
> syntax as the Unicode string syntax --- see
> http://developer.postgresql.org/pgdocs/postgres/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-UESCAPE
>
> I think we need
On Sat, Apr 11, 2009 at 11:13:59AM -0400, Tom Lane wrote:
> My own take on it is that actually I'd prefer one command for all of
> these. If I say "\df sum" it would be good if the output included the
> sum() aggregates; the reason being that I might be wondering if I can
> create a plain function
Sam Mason writes:
> On Sat, Apr 11, 2009 at 11:13:59AM -0400, Tom Lane wrote:
>> If we were designing in a green field I think you could make a real
>> strong case for a single \df command with an output column "type" having
>> the alternatives regular, aggregate, window, and maybe trigger.
> Wha
On Sat, Apr 11, 2009 at 8:58 AM, David Fetter wrote:
> On Sat, Apr 11, 2009 at 08:52:31AM -0400, Robert Haas wrote:
>> On Sat, Apr 11, 2009 at 5:06 AM, Grzegorz Jaskiewicz
>> wrote:
>> > On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
>> >> 2009/4/11 David Fetter :
>> >>> On Sat, Apr 11, 2009 at
Hello,
I am sending small patch, that allows hooking transformation stage of parser.
Regards
Pavel Stehule
*** ./src/backend/parser/parse_expr.c.orig 2009-03-17 16:20:18.0 +0100
--- ./src/backend/parser/parse_expr.c 2009-03-17 16:24:43.0 +0100
***
*** 36,41
--- 3
Pavel Stehule writes:
> I am sending small patch, that allows hooking transformation stage of parser.
Isn't this the exact same patch we rejected several months ago?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
2009/4/11 Tom Lane :
> Pavel Stehule writes:
>> I am sending small patch, that allows hooking transformation stage of parser.
>
> Isn't this the exact same patch we rejected several months ago?
>
> regards, tom lane
What I remember, You had some objections about different
On Monday 06 April 2009 04:29:02 Tom Lane wrote:
> The only question I have is whether we want this nag message or not:
>
> ! ereport(LOG,
> ! (errcode(ERRCODE_INTERNAL_ERROR),
> ! errmsg("Picksplit method for %d column of index \"%s\"
> failed", !
Pavel Stehule writes:
> 2009/4/11 Tom Lane :
>> Pavel Stehule writes:
>>> I am sending small patch, that allows hooking transformation stage of
>>> parser.
>>
>> Isn't this the exact same patch we rejected several months ago?
> What I remember, You had some objections about different behave be
Tom Lane wrote:
It gets worse though: I have seldom seen such a badly designed piece of
syntax as the Unicode string syntax --- see
http://developer.postgresql.org/pgdocs/postgres/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-UESCAPE
You scan the string, and then after that they tell you what the
Peter Eisentraut writes:
> On Monday 06 April 2009 04:29:02 Tom Lane wrote:
>> The only question I have is whether we want this nag message or not:
> If it is supposed to be DEBUG1, would you mind if I convert it to an elog so
> it doesn't appear in the translation roster?
Okay with me. You co
Tom Lane wrote:
> Abhijit Menon-Sen writes:
> > There's a TODO item about making COMMENT ON accept an expression. The
> > grammar change is simple (SConst|NULL_P->a_expr), but as far as I can
> > see, there are no similar utility commands that take expressions, and
> > I'm not very familiar with t
2009/4/11 Tom Lane :
> Pavel Stehule writes:
>> 2009/4/11 Tom Lane :
>>> Pavel Stehule writes:
I am sending small patch, that allows hooking transformation stage of
parser.
>>>
>>> Isn't this the exact same patch we rejected several months ago?
>
>> What I remember, You had some object
2009/4/11 Bruce Momjian :
> Tom Lane wrote:
>> Abhijit Menon-Sen writes:
>> > There's a TODO item about making COMMENT ON accept an expression. The
>> > grammar change is simple (SConst|NULL_P->a_expr), but as far as I can
>> > see, there are no similar utility commands that take expressions, and
Pavel Stehule writes:
> 2009/4/11 Bruce Momjian :
>> I remember adding the TODO after a request from the user, but I have not
>> seen further requests. I have remove the item; let's see if we get any
>> further requests for it.
> I thing so this TODO point is little bit step in bad direction.
I
> like (pseudo-code here)
>
> execute('COMMENT ON foo IS $1', some_string);
>
> and let the out-of-line-parameter mechanism take care of quoting and
> escaping your string. This doesn't work today, and I remember having
> seen complaints about that on the JDBC list. So there's a use-case a
On 4/10/09 10:13 PM, Jaime Casanova wrote:
On Fri, Apr 10, 2009 at 11:47 PM, Abhijit Menon-Sen wrote:
Hi.
There's a TODO item about making COMMENT ON accept an expression.
really? what's the use case for that?
Easy: if you want to add comments to database objects generated in
stored proc
Pavel Stehule writes:
> But the proc
> CREATE OR REPLACE FUNCTION some_proc(tabname varchar)
> RETURNS void AS $$
> BEGIN
> EXECUTE 'CREATE TABLE $1(a integer)' USING tabname;
> is more readable than EXECUTE 'CREATE TABLE ' || tabname || '(
I was intentionally excluding the idea of substit
2009/4/11 Tom Lane :
> Pavel Stehule writes:
>> But the proc
>> CREATE OR REPLACE FUNCTION some_proc(tabname varchar)
>> RETURNS void AS $$
>> BEGIN
>> EXECUTE 'CREATE TABLE $1(a integer)' USING tabname;
>
>> is more readable than EXECUTE 'CREATE TABLE ' || tabname || '(
>
> I was intentiona
On 4/11/09, Tom Lane wrote:
> It gets worse though: I have seldom seen such a badly designed piece of
> syntax as the Unicode string syntax --- see
>
> http://developer.postgresql.org/pgdocs/postgres/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-UESCAPE
>
> You scan the string, and then after th
All,
Having an extra column in \df for "Windowing" was rejected out of hand.
Why?
\df (let alone \df+) already displays too many wide columns to fit in
any standard terminal window. You're pretty much forced to use \x
regardless. What's one more column?
And has it occurred to anyone th
On 4/11/09 11:47 AM, Marko Kreen wrote:
On 4/11/09, Tom Lane wrote:
It gets worse though: I have seldom seen such a badly designed piece of
syntax as the Unicode string syntax --- see
http://developer.postgresql.org/pgdocs/postgres/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-UESCAPE
WTF
Josh Berkus writes:
> Having an extra column in \df for "Windowing" was rejected out of hand.
> Why?
I'd definitely support adding it to \df+. Basic \df might be a harder
sell, because it still does mostly fit in 80 columns now, but would
certainly no longer do so with another column.
> And
Josh Berkus writes:
>> On 4/11/09, Tom Lane wrote:
>>> http://developer.postgresql.org/pgdocs/postgres/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-UESCAPE
> WTF? Whose feature is this? What's the use case?
Peter put it in, I think. It is in the SQL:2008 spec, but that doesn't
change the fact
Tom,
It fits into 80 columns if you don't have any functions with 11
parameters. ;-)
Actually, I'm thinking the new column ought to be called "type". That
way, it could be "window" or "trigger" or "internal", and more types
later if we develop any (like "MED").
Too late for 8.4 I'm afra
Peter put it in, I think. It is in the SQL:2008 spec, but that doesn't
change the fact that it's a horribly bad piece of design.
Hmmm. We're not going to implement *everything* in the spec; nobody
does, even IBM. I think maybe these kinds of additions need to be
hashed out for value so we
Josh Berkus writes:
> Tom,
> It fits into 80 columns if you don't have any functions with 11
> parameters. ;-)
Well, yeah, but in typical cases I think it fits. A look at the current
regression database shows all but 6 of 117 functions fitting. With
another ten characters eaten by a new colum
On Sat, Apr 11, 2009 at 03:12:39PM -0400, Tom Lane wrote:
> Josh Berkus writes:
> > Tom, It fits into 80 columns if you don't have any functions with
> > 11 parameters. ;-)
>
> Well, yeah, but in typical cases I think it fits. A look at the
> current regression database shows all but 6 of 117 f
David Fetter wrote:
> On Sat, Apr 11, 2009 at 03:12:39PM -0400, Tom Lane wrote:
> > Josh Berkus writes:
> > > Tom, It fits into 80 columns if you don't have any functions with
> > > 11 parameters. ;-)
> >
> > Well, yeah, but in typical cases I think it fits. A look at the
> > current regression
On Sat, Apr 11, 2009 at 2:47 PM, Josh Berkus wrote:
> All,
>
> Having an extra column in \df for "Windowing" was rejected out of hand.
> Why?
I have no idea. I suggested it and the only one I remember speaking
against it was Tom.
> \df (let alone \df+) already displays too many wide columns t
On Sat, Apr 11, 2009 at 03:34:31PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > On Sat, Apr 11, 2009 at 03:12:39PM -0400, Tom Lane wrote:
> > > Josh Berkus writes:
> > > > Tom, It fits into 80 columns if you don't have any functions with
> > > > 11 parameters. ;-)
> > >
> > > Well, yeah
Bruce Momjian writes:
> I assume the 'type' column will identify triggers, i/o functions
> (cstring), window functions, and maybe aggregates too; this solves
> several problems at once.
+1 for all except i/o functions. The cstring check for that was always
flat-out wrong, and getting it right i
Is there any way to adjust the oid of an already created pg_type (plus
dependent tables like pg_attribute)? C code inside the backend is
ok...I have two databases and need to keep oid in sync.
(or, create a type at a particular oid slot would be ok too). note,
this is not at bootstrap time.
mer
On Sat, Apr 11, 2009 at 04:30:02PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I assume the 'type' column will identify triggers, i/o functions
> > (cstring), window functions, and maybe aggregates too; this solves
> > several problems at once.
>
> +1 for all except i/o functions. The cs
Merlin Moncure writes:
> Is there any way to adjust the oid of an already created pg_type
No.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Merlin Moncure escribió:
> (or, create a type at a particular oid slot would be ok too). note,
> this is not at bootstrap time.
We needed fixed OIDs for some things in Replicator, and the only way I
could see about it was to hack up a special bootstrap mode.
It's a pain :-( But since we patch
Tom Lane wrote:
> A thread over in -admin has made me realize the truth of $SUBJECT.
> With --clean, pg_dumpall does indeed emit a DROP command for each
> role, tablespace, or database ... just before recreating it. This
> takes no account of dependencies and so the role and tablespace
> drops are
Tom Lane wrote:
Merlin Moncure writes:
Is there any way to adjust the oid of an already created pg_type
No.
Then why are oids sent in some type's external binary format? If you
can't fix oids, external format is useless to the outside world. Since
you CAN modify a type's name all day
Bruce Momjian writes:
> Does your recently-applied patch address any of these TODO items?
> Stop dumping CASCADE on DROP TYPE commands in clean mode
That has nothing to do with pg_dumpall.
> Allow pg_dump --clean to drop roles that own objects or
> have privileges
Hm
Andrew Chernow writes:
> Tom Lane wrote:
>> Merlin Moncure writes:
>>> Is there any way to adjust the oid of an already created pg_type
>>
>> No.
> Then why are oids sent in some type's external binary format?
How is that related?
> If you
> can't fix oids, external format is useless to the
Tom Lane wrote:
Andrew Chernow writes:
Tom Lane wrote:
Merlin Moncure writes:
Is there any way to adjust the oid of an already created pg_type
No.
Then why are oids sent in some type's external binary format?
How is that related?
Well, the format is called "external", yet the oid is
At 2009-04-11 14:08:21 -0400, t...@sss.pgh.pa.us wrote:
>
> So there's a use-case at least for allowing parameter symbols in place
> of string literals, if not fully general expressions. But again, I
> think we'd want such a thing across all utility statements that can
> take string literals, not o
On Sat, Apr 11, 2009 at 01:43:35PM -0700, David Fetter wrote:
> On Sat, Apr 11, 2009 at 04:30:02PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I assume the 'type' column will identify triggers, i/o functions
> > > (cstring), window functions, and maybe aggregates too; this solves
> > >
Robert,
For what purpose?
See above, in thread.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Fetter writes:
> It occurs to me that we ought to allow for a possibility that a
> function can be more than one special case. For example, sum() is
> both an aggregate and a windowing function, while rank() is only a
> windowing function.
If it makes the display even one character wider,
On Sat, Apr 11, 2009 at 07:35:54PM -0400, Tom Lane wrote:
> David Fetter writes:
> > It occurs to me that we ought to allow for a possibility that a
> > function can be more than one special case. For example, sum() is
> > both an aggregate and a windowing function, while rank() is only a
> > win
After spending some time with the new plural string translation support,
I admit I am confused.
I was just going over this string in pg_dump:
#: pg_dump.c:5011
#, c-format
msgid "expected %d check constraint on table \"%s\" but found %d\n"
msgid_plural "expected %d check constraints on table \"%s
Alvaro Herrera wrote:
> #: pg_dump.c:5011
> #, c-format
> msgid "expected %d check constraint on table \"%s\" but found %d\n"
> msgid_plural "expected %d check constraints on table \"%s\" but found %d\n"
Sorry, I'm an idiot -- the one I wanted to paste was
#: pg_dump.c:6344 pg_dump.c:6543 pg_dum
On Thu, Feb 19, 2009 at 5:53 PM, Tom Lane wrote:
> Greg Stark writes:
>> It's tempting to have Hash cheat and just peek at the node beneath it
>> to see if it's a HashAggregate, in which case it could call a special
>> method to request the whole hash. But it would have to know that it's
>> just
63 matches
Mail list logo
