"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> On Sunday 09 July 2006 20:00, Greg Stark wrote:
>> BIRT pgsql-patches should be abolished in favour of something else that
>> accomplishes the bandwidth-reduction aspect without the downsides.
> Alternatively, people could just use patches for patch
Greg Stark <[EMAIL PROTECTED]> writes:
> The SQL spec has some detailed discussion of some strange null behaviours.
BTW, Teodor Sigaev pointed out today that we are also doing array
comparisons (array_eq, array_cmp) wrong. In the recent extension
to make arrays support NULL entries, I had made th
On Mon, 9 Jul 2006, Greg Stark wrote:
Pursuant to a conversation this evening I would like to a suggestion:
BIRT pgsql-patches should be abolished in favour of something else that
accomplishes the bandwidth-reduction aspect without the downsides.
My complaint is that -patches serves to
a) si
On Sunday 09 July 2006 20:00, Greg Stark wrote:
> Pursuant to a conversation this evening I would like to a suggestion:
>
> BIRT pgsql-patches should be abolished in favour of something else that
> accomplishes the bandwidth-reduction aspect without the downsides.
Alternatively, people could jus
Greg Stark <[EMAIL PROTECTED]> writes:
> The SQL spec has some detailed discussion of some strange null behaviours.
Sorry, forgot the reference. This is section 8.7 "" of the
SQL/Foundation. Pages 397-398 in this draft.
--
greg
---(end of broadcast)---
The SQL spec has some detailed discussion of some strange null behaviours.
Specifically "row(1,null) is null" is false but "row(1,null) is not null" is
*also* supposed to be false. Postgres currently gets this wrong. "is [not]
null" is apparently supposed to mean "all the fields are (not) null".
While replying to the "information_schema for all users" thread in
pgsql-sql I noticed that a cursor returned from a SECURITY DEFINER
function evalutes current_user as the user who executes FETCH, not
as the user who defined the function that opened the cursor. Here
are the question and my respons
Pursuant to a conversation this evening I would like to a suggestion:
BIRT pgsql-patches should be abolished in favour of something else that
accomplishes the bandwidth-reduction aspect without the downsides.
My complaint is that -patches serves to
a) siphon off some of the most technical dis
A while ago in connection with the 8.2 planning [1] there was some
discussion of resource management and statement queuing [2].
I am currently looking at implementing a resource management/queuing
module for Greenplum - initially targeting Bizgres, but I'm thinking it
could be beneficial for non-
On Monday 10 July 2006 00:29, Martijn van Oosterhout wrote:
> On Sun, Jul 09, 2006 at 10:08:42PM +0300, Tzahi Fadida wrote:
> > They return format_type_be(INT4OID) = "integer" or
> > format_type_be(FLOAT8OID) = "double precision"
> > I need to use this in a query with the "::" cast operator.
>
> Th
On Sun, Jul 09, 2006 at 10:08:42PM +0300, Tzahi Fadida wrote:
> They return format_type_be(INT4OID) = "integer" or format_type_be(FLOAT8OID)
> = "double precision"
> I need to use this in a query with the "::" cast operator.
The problem being?
test=# select '1'::integer, '4.5'::double precision;
On Sunday 09 July 2006 21:49, Michael Fuhr wrote:
> On Sun, Jul 09, 2006 at 09:03:21PM +0300, Tzahi Fadida wrote:
> > How do i get a char * type from a type Oid. i.e.
> > getStringTypeFromOid(INT4OID) will return "int4".
>
> Server-side or client-side? In the backend I think you could use
Backend
On Sun, Jul 09, 2006 at 09:03:21PM +0300, Tzahi Fadida wrote:
> How do i get a char * type from a type Oid. i.e.
> getStringTypeFromOid(INT4OID)
> will return "int4".
Server-side or client-side? In the backend I think you could use
format_type_be() or format_type_with_typemod(), both declared i
On Sun, Jul 09, 2006 at 11:24:38AM -0400, Phil Frost wrote:
> On UNIX it is also clearly defined that if one does not have execute
> permissions on a directory, one can not open files within it by *any*
> *means*. There are no procedures that bypass this by taking an inode
> number directly.
Well,
Hi,
How do i get a char * type from a type Oid. i.e. getStringTypeFromOid(INT4OID)
will return "int4".
10x.
--
Regards,
Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS: see at
http://members.lycos.co.uk/my2nis/spamwarning
On Sun, Jul 09, 2006 at 02:32:24PM +0200, Martijn van Oosterhout wrote:
> On Sat, Jul 08, 2006 at 05:47:33PM -0400, Jim Nasby wrote:
> > On Jul 6, 2006, at 11:02 AM, Phil Frost wrote:
> > >I hope the above example is strong enough to elicit a comment from a
> > >qualified developer. If it is not, c
On Sat, Jul 08, 2006 at 05:54:26PM -0400, Jim Nasby wrote:
> +1. If there's enough user demand we can look at adding the type to
> core (I don't see any real advantage to contrib over pgFoundry for
> this). I'm not sure if it makes sense to add a generic 16 byte RAW to
> core, either. I'd *mu
On Sat, Jul 08, 2006 at 05:47:33PM -0400, Jim Nasby wrote:
> On Jul 6, 2006, at 11:02 AM, Phil Frost wrote:
> >I hope the above example is strong enough to elicit a comment from a
> >qualified developer. If it is not, consider that stored procedures
> >contain prepared statements, and many client a
18 matches
Mail list logo
