Log Message:
---
2006-06-16 Francisco Figueiredo Jr. <[EMAIL PROTECTED]>
* NpgsqlTypesHelper.cs: [#1000551] Incorrect conversion of decimal type
causes ERROR: 22P02: invalid input syntax for type numeric. When using prepared
commands, decimal numbers were being sent with wrong
Log Message:
---
Test for POSIX_FADV_DONTNEED to use posix_fadvise().
Modified Files:
--
pgsql/src/backend/access/transam:
xlog.c (r1.238 -> r1.239)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c.diff?r1=1.238&r2=1.239)
Log Message:
---
Fix:
< get_employee_salary(emp_id AS 12345, tax_year AS 2001)
> get_employee_salary(12345 AS emp_id, 2001 AS tax_year)
Modified Files:
--
pgsql/doc:
TODO (r1.1881 -> r1.1882)
(http://developer.postgresql.org
Log Message:
---
Update magic block wording for preloaded libraries.
Modified Files:
--
pgsql/doc/src/sgml:
config.sgml (r1.62 -> r1.63)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml.diff?r1=1.62&r2=1.63)
--
Log Message:
---
Changed the generate alternatives algorithm to use components instead of JCC
heuristic. Fixed the output bug. Fixed a bug in varUnSetNthBitFromLeft. moved
to deformed tuple in generate alternative tuple set.
Modified Files:
--
fd:
algstructs.c (r1
Bruce Momjian writes:
> We had reasonable problems with Oracle's outer-join syntax, while I
> don't see the same fundamental issue with => vs AS, and PL/pgSQL is
> patterned on Oracle's PL/SQL.
The fundamental issue is reserving what used to be an available operator
name, in the service of a synt
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> The odds of that syntax getting accepted may not be exactly zero, but
> >> they are certainly vanishingly small. I thought we'd agreed that a
> >> usable syntax would be like
> >> get_employee_salary(12345 AS emp_id, 2001 AS tax_yea
Bruce Momjian writes:
> Tom Lane wrote:
>> The odds of that syntax getting accepted may not be exactly zero, but
>> they are certainly vanishingly small. I thought we'd agreed that a
>> usable syntax would be like
>> get_employee_salary(12345 AS emp_id, 2001 AS tax_year)
> TODO updated, but I th
Log Message:
---
Use posix_fadvise() to avoid kernel caching of WAL contents on WAL file
close.
ITAGAKI Takahiro
Modified Files:
--
pgsql/src/backend/access/transam:
xlog.c (r1.237 -> r1.238)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/ac
Log Message:
---
Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if more or
less than one row is returned by the SELECT, for Oracle PL/SQL
compatibility.
Improve SELECT INTO documentation.
Matt Miller
Modified Files:
--
pgsql/doc/src/sgml:
plpgsql.sgm
David Fetter wrote:
> On Thu, Jun 15, 2006 at 01:42:10PM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > [EMAIL PROTECTED] (Bruce Momjian) writes:
> > > >> o Allow function parameters to be passed by name,
> > > >> get_employee_salary(emp_id => 12345, tax_year => 2001)
> > >
> > > The odds o
On Thu, Jun 15, 2006 at 01:42:10PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > [EMAIL PROTECTED] (Bruce Momjian) writes:
> > >> o Allow function parameters to be passed by name,
> > >> get_employee_salary(emp_id => 12345, tax_year => 2001)
> >
> > The odds of that syntax getting accepted may
Log Message:
---
Fix to_ascii() markup error.
Modified Files:
--
pgsql/doc/src/sgml:
func.sgml (r1.320 -> r1.321)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/func.sgml.diff?r1=1.320&r2=1.321)
---(end of broadcast)
Log Message:
---
Add mention that preload_libraries check the magic block, so
non-PostgreSQL libraries cannot be loaded using this capability.
Modified Files:
--
pgsql/doc/src/sgml:
config.sgml (r1.61 -> r1.62)
(http://developer.postgresql.org/cvsweb.cgi/pg
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> >> o Allow function parameters to be passed by name,
> >> get_employee_salary(emp_id => 12345, tax_year => 2001)
>
> The odds of that syntax getting accepted may not be exactly zero, but
> they are certainly vanishingly small. I though
Log Message:
---
Update syntax suggestion:
< get_employee_salary(emp_id => 12345, tax_year => 2001)
> get_employee_salary(emp_id AS 12345, tax_year AS 2001)
Modified Files:
--
pgsql/doc:
TODO (r1.1880 -> r1.1881)
(http://dev
Log Message:
---
Move list of supported to_ascii() encodings from footnote to main
description.
Nis Jorgensen
Modified Files:
--
pgsql/doc/src/sgml:
func.sgml (r1.319 -> r1.320)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/func.sgml.diff?
Log Message:
---
Add:
>
> o Fix memory leak from exceptions
>
>
> http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php
Modified Files:
--
pgsql/doc:
TODO (r1.1879 -> r1.1880)
(http://developer.postgresql.or
[EMAIL PROTECTED] (Bruce Momjian) writes:
>> o Allow function parameters to be passed by name,
>> get_employee_salary(emp_id => 12345, tax_year => 2001)
The odds of that syntax getting accepted may not be exactly zero, but
they are certainly vanishingly small. I thought we'd agreed that a
usable
Log Message:
---
Clarify dynamic pl/pgsql item and add URLs. Restructure server-side
section into PL/pgSQL and non-PL/pgSQL sections:
< o Fix PL/pgSQL RENAME to work on variables other than OLD/NEW
< o Allow function parameters to be passed by name,
< get_employee_sala
Log Message:
---
Add:
> o Allow PL/PgSQL RETURN to return row or record functions
>
> http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
Modified Files:
--
pgsql/doc:
TODO (r1.1877 -> r1.1878)
(http://developer.postgresql.org/
21 matches
Mail list logo
