Josh Berkus wrote:
>
>> The patch adds the "AS" keyword to the plpgsql grammar and doesn't
>> assign an expression parameter to the sql construct if the scalar
>> follows the AS keyword.
>
> Would it be possible to also support "=" as well as "as"? I believe
> that SQL Server uses "=" exclusivel
"=" is more common than "as" for sure, but this has been talked about
before starting at about this message:
http://archives.postgresql.org/message-id/14319.1228833...@sss.pgh.pa.us
-Steve
On May 21, 2009, at 11:51 AM, Josh Berkus wrote:
The patch adds the "AS" keyword to the plpgsql gramm
2009/5/21 Pavel Stehule :
> 2009/5/21 Josh Berkus :
>>
>>> The patch adds the "AS" keyword to the plpgsql grammar and doesn't
>>> assign an expression parameter to the sql construct if the scalar
>>> follows the AS keyword.
>>
>> Would it be possible to also support "=" as well as "as"? I believe
2009/5/21 Josh Berkus :
>
>> The patch adds the "AS" keyword to the plpgsql grammar and doesn't
>> assign an expression parameter to the sql construct if the scalar
>> follows the AS keyword.
>
> Would it be possible to also support "=" as well as "as"? I believe that
> SQL Server uses "=" exclusi
The patch adds the "AS" keyword to the plpgsql grammar and doesn't
assign an expression parameter to the sql construct if the scalar
follows the AS keyword.
Would it be possible to also support "=" as well as "as"? I believe
that SQL Server uses "=" exclusively, and supporting that syntax wo
On May 21, 2009, at 10:52 AM, Tom Lane wrote:
It's probably time to bite the bullet and redo the parser as has been
suggested in the past, ie fix things so that the main parser is used.
Ideally I'd like to switch the name resolution priority to be more
Oracle-like, but even if we don't do that it
--
Greg
On 21 May 2009, at 12:26, Tom Lane wrote:
Greg Stark writes:
On Thu, May 21, 2009 at 4:22 PM, Tom Lane wrote:
Yeah ... I don't see exactly what it would buy to restrict it to
just
the first such value.
Well it wouldn't buy you steady-state space savings or performance
i
Steve Prentice writes:
> This patch is intended to supplement Pavel's patch for named and mixed
> notation support in 8.5. This patch makes it so a plpgsql function can
> call another function with the same parameter names using the named
> parameters notation.
Well, plpgsql's parsing has a
Hello,
This patch is intended to supplement Pavel's patch for named and mixed
notation support in 8.5. This patch makes it so a plpgsql function can
call another function with the same parameter names using the named
parameters notation. Without this patch, the following example will
have
Greg Stark writes:
> On Thu, May 21, 2009 at 4:22 PM, Tom Lane wrote:
>> Yeah ... I don't see exactly what it would buy to restrict it to just
>> the first such value.
> Well it wouldn't buy you steady-state space savings or performance
> improvements.
> What it would buy you is a much narrowe
On Thu, May 21, 2009 at 4:22 PM, Tom Lane wrote:
> Greg Stark writes:
>> Schemes like this have been discussed before but I don't think we
>> considered applying the limitation that only the "first" default value
>> would be covered. We always wanted to be able to handle new defaults
>> or making
On Thu, May 21, 2009 at 11:13 AM, Greg Stark wrote:
> On Thu, May 21, 2009 at 3:45 PM, Tom Lane wrote:
>>
>>> All that needs to be tracked is the "first" default value (this is
>>> currently assumed to be NULL).
>>
>> You're being a bit vague, but in any case I don't think it can work
>> for non-
Greg Stark writes:
> Schemes like this have been discussed before but I don't think we
> considered applying the limitation that only the "first" default value
> would be covered. We always wanted to be able to handle new defaults
> or making a non-null column nullable later.
Yeah ... I don't see
Heikki Linnakangas píše v čt 21. 05. 2009 v 16:53 +0300:
> Zdenek Kotala wrote:
> > last version of psql is broken:
> >
> > psql (8.4beta1, server 8.3.7)
> > WARNING: psql version 8.4, server version 8.3.
> > Some psql features might not work.
> > Type "help" for help.
> >
> > postgres=#
On Thu, May 21, 2009 at 3:45 PM, Tom Lane wrote:
>
>> All that needs to be tracked is the "first" default value (this is
>> currently assumed to be NULL).
>
> You're being a bit vague, but in any case I don't think it can work
> for non-constant defaults (consider DEFAULT NOW()). And what about
>
On Thu, May 21, 2009 at 10:45 AM, Tom Lane wrote:
> Sam Mason writes:
>> On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
>>> ALTER TABLE ... ADD COLUMN ... NULL;
>>>
>>> (nullable without a default value). This is because of NULL bitmap in
>>> tuples. And it's greatest feature for
Sam Mason writes:
> On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
>> ALTER TABLE ... ADD COLUMN ... NULL;
>>
>> (nullable without a default value). This is because of NULL bitmap in
>> tuples. And it's greatest feature for a developer!
> I don't think this is because of the "NU
Zdenek Kotala wrote:
last version of psql is broken:
psql (8.4beta1, server 8.3.7)
WARNING: psql version 8.4, server version 8.3.
Some psql features might not work.
Type "help" for help.
postgres=# \d test
ERROR: syntax error at or near ","
LINE 1: ...index, relhasrules, reltriggers <
On Thu, May 21, 2009 at 8:51 AM, Greg Stark wrote:
> Having just raised the statistics targets I wonder if we should look
> at raising these two parameters too. The experience on the lists are
> that when people run into either of these two limits we recommend
> raising them and we've never seen a
Having just raised the statistics targets I wonder if we should look
at raising these two parameters too. The experience on the lists are
that when people run into either of these two limits we recommend
raising them and we've never seen anyone come back complaining that
their planning time goes th
Hi all,
last version of psql is broken:
psql (8.4beta1, server 8.3.7)
WARNING: psql version 8.4, server version 8.3.
Some psql features might not work.
Type "help" for help.
postgres=# \d test
ERROR: syntax error at or near ","
LINE 1: ...index, relhasrules, reltriggers <> 0, relhasoid
On Thursday 21 May 2009 14:29:51 Tom Lane wrote:
> Peter Eisentraut writes:
> > On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote:
> >> Hmm, the patch looks fine to me. The strings are marked with
> >> gettext_noop() in the array, and passed through _() when used in errmsg.
> >
> > But his
On Thu, May 21, 2009 at 7:50 AM, Tom Lane wrote:
> Josh Berkus writes:
>> Robert,
>>> It appears that this statement has been in our documentation since Tom
>>> Lane added FROM_COLLAPSE_LIMIT (back then, it was capitalized) on
>>> January 25, 2003 (9bf97ff426de9), but I can't find any justificati
Josh Berkus writes:
> Robert,
>> It appears that this statement has been in our documentation since Tom
>> Lane added FROM_COLLAPSE_LIMIT (back then, it was capitalized) on
>> January 25, 2003 (9bf97ff426de9), but I can't find any justification
>> for it anywhere. I think we either need to justif
Robert Haas writes:
> We currently have a (really handy) facility to pull a message from the
> archives by message-ID, eg:
> http://archives.postgresql.org/message-id/603c8f070905202040v66cd3054t434c0b73aa844...@mail.gmail.com
> Could we possibly get a similar type of link that pulls the raw
> c
> (In most cases NOT NULL DEFAULT xxx fields are BOOLEAN, flags: it is not
> handy to have 3-way flags.)
This is certainly not true for me. I have both nullable booleans and
not-nullable, defaulted columns of other types.
> So, are there plans to optimize such kind of queries? This could be done
Peter Eisentraut writes:
> On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote:
>> Hmm, the patch looks fine to me. The strings are marked with
>> gettext_noop() in the array, and passed through _() when used in errmsg.
> But his patch changes that to
> errhint("%s", _(wentry->drophint_msg
On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
> ALTER TABLE ... ADD COLUMN ... NULL;
>
> (nullable without a default value). This is because of NULL bitmap in
> tuples. And it's greatest feature for a developer!
I don't think this is because of the "NULL bitmap". PG just never
On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote:
> Peter Eisentraut wrote:
> > Note that applying this patch would introduce a double-translation issue
> > of the sort that you had complained about a while ago. I'm unsure which
> > way to proceed here.
>
> Hmm, the patch looks fine to me
On Thursday 21 May 2009 11:06:29 Dmitry Koterov wrote:
> 1. Store the DEFAULT flag directly in NULL BITMAP (add a bit to NULL bitmap
> not only for NULLable fields, but also for NOT NULL DEFAULT ... fields).
> 2. Add another bitmap for each tuple (DEFAULT bitmap). Bit value 0 means
> that there is
Hello.
PostgreSQL is very fast when we perform (even on a huge table)
ALTER TABLE ... ADD COLUMN ... NULL;
(nullable without a default value). This is because of NULL bitmap in
tuples. And it's greatest feature for a developer!
But another very common-case query like
ALTER TABLE ... ADD COLUM
Peter Eisentraut wrote:
Note that applying this patch would introduce a double-translation issue of
the sort that you had complained about a while ago. I'm unsure which way to
proceed here.
Hmm, the patch looks fine to me. The strings are marked with
gettext_noop() in the array, and passed t
32 matches
Mail list logo
