Martijn van Oosterhout writes:
> Something that has been discussed in the past is allowing non-strict
> type input/output functions to be evaluated at query execution time,
> rather than during parse time. This would give the type input/output
> functions the Expr node they need to extract this in
Martijn van Oosterhout writes:
> On Sat, Jul 01, 2006 at 10:37:59AM -0400, Tom Lane wrote:
>> The output function, however, would be quite a trick.
>> It's not going to receive anything except the Datum itself.
> Hmm, you're right. With the taggedtypes module I made it work by
> cloning the outpu
On Sat, Jul 01, 2006 at 10:58:05AM -0400, Andrew Dunstan wrote:
> Tom Lane wrote:
>
> >The output function, however, would be quite a trick.
> >It's not going to receive anything except the Datum itself.
>
> I understand the reasons for this limitation of output functions, but I
> have now seen
Tom Lane wrote:
The output function, however, would be quite a trick.
It's not going to receive anything except the Datum itself.
I understand the reasons for this limitation of output functions, but I
have now seen it bite several times. Maybe we need a little out of the
box
On Sat, Jul 01, 2006 at 10:37:59AM -0400, Tom Lane wrote:
> > Where these input/output functions would work for any given length, so
> > the 16 could be replaced by any number, or even -1 to make a variable
> > length type...
>
> I believe you could make an input function that would support that,
Martijn van Oosterhout writes:
> It would also be possible to provide two functions called hex_raw_in()
> and hex_raw_out() that people could use like so:
> CREATE TYPE uuid (
> input = hex_raw_in,
> output = hex_raw_out,
> INTERNALLENGTH = 16
> );
> Where these input/output functions woul
On Fri, Jun 30, 2006 at 12:45:13PM -0500, Jim C. Nasby wrote:
> > If people agree to a generic 16-byte type, or a hex type with defined
> > fixed length with a set of standard functions and index operators that
> > it should work for, but nobody more qualified wants to make the patch
> > - I'll ste
[EMAIL PROTECTED] writes:
> It depends how it is used. If the memory location needs to be
> allocated, for the value to be used only a few times, the overhead of
> allocation and redirection can be more expensive. If many though, than
> the reduction in value copying can make the pointer faster. 64
On Fri, Jun 30, 2006 at 12:39:52PM -0400, [EMAIL PROTECTED] wrote:
> > Only this could be used to create other types too, for cryptographic
> > functions for example. PostgreSQL doesn't have any type generators yet,
> > so I'm unsure whether a patch creating one would be accepted for core.
>
> Not
On Fri, Jun 30, 2006 at 10:38:49AM +0200, Martijn van Oosterhout wrote:
> On Fri, Jun 30, 2006 at 04:04:19AM -0400, [EMAIL PROTECTED] wrote:
> > > > It seems to me that maybe the backend should include a 16-byte fixed
> > > > length object (after all, we've got 1, 2, 4 and 8 bytes already) and
> >
On Fri, Jun 30, 2006 at 04:04:19AM -0400, [EMAIL PROTECTED] wrote:
> > Martijn van Oosterhout wrote:
> > > It seems to me that maybe the backend should include a 16-byte fixed
> > > length object (after all, we've got 1, 2, 4 and 8 bytes already) and
> > > then people can use that to build whatever
On Fri, Jun 30, 2006 at 08:53:28AM +0200, Thomas Hallgren wrote:
> Josh Berkus wrote:
> >> I agree about splitting the utilities, except that I think the database
> >> should be able to generate UUIDs somehow.
> > There is a GUID add-in, and someone is working on a 2nd one. UUIDs
> > are not part
Josh Berkus wrote:
> Jim,
>
>> I agree about splitting the utilities, except that I think the database
>> should be able to generate UUIDs somehow.
>
> There is a GUID add-in, and someone is working on a 2nd one. UUIDs
are not part of the SQL standard, and we've only seen sporadic demand
for th
Jim,
I agree about splitting the utilities, except that I think the database
should be able to generate UUIDs somehow.
There is a GUID add-in, and someone is working on a 2nd one. UUIDs are
not part of the SQL standard, and we've only seen sporadic demand for
them (and different types each
On Thu, Jun 29, 2006 at 09:12:32AM +0200, Thomas Hallgren wrote:
> The split make sense since clients often have powerful UUID utilities handy
> and hence have limited or no use for such utilities in the database (true
> for all .NET and Java clients). Some PL's will also enable such packages
>
If there is interest - I'm sure Nathan and I would be willing to put
it on pgfoundry, and at some point give it up for inclusion into
PostgreSQL.
One requirement would be that it runs on Windows. Is that something you
have tested?
In case it influences anyone, MySQL 5 already has built-in UUID
[EMAIL PROTECTED] wrote:
On Thu, Jun 29, 2006 at 02:02:32AM -0400, [EMAIL PROTECTED] wrote:
It was written by Nathan Wagner <[EMAIL PROTECTED]> and myself, and
is based off the OSSP ( http://www.ossp.org/ ) UUID implementation.
I'm not an expert on the license, but it seems acceptable to me:
...
[EMAIL PROTECTED] wrote:
On Wed, Jun 28, 2006 at 01:12:17PM -0500, Jim C. Nasby wrote:
On Wed, Jun 28, 2006 at 01:49:55PM -0400, Andrew Dunstan wrote:
Personally I don't buy the misuse objection - we already have plenty of
things that can be misused. As long as there is a reasonable valid use
On Thu, Jun 29, 2006 at 02:02:32AM -0400, [EMAIL PROTECTED] wrote:
> It was written by Nathan Wagner <[EMAIL PROTECTED]> and myself, and
> is based off the OSSP ( http://www.ossp.org/ ) UUID implementation.
> I'm not an expert on the license, but it seems acceptable to me:
> ...
> If there is inter
On Wed, Jun 28, 2006 at 01:12:17PM -0500, Jim C. Nasby wrote:
> On Wed, Jun 28, 2006 at 01:49:55PM -0400, Andrew Dunstan wrote:
> > Personally I don't buy the misuse objection - we already have plenty of
> > things that can be misused. As long as there is a reasonable valid use
> > and we can mak
On Wed, Jun 28, 2006 at 01:49:55PM -0400, Andrew Dunstan wrote:
> Personally I don't buy the misuse objection - we already have plenty of
> things that can be misused. As long as there is a reasonable valid use
> and we can make it portable enough, I think there is a good case for
> including it
[EMAIL PROTECTED] wrote:
> I've downloaded the version off pgfoundry.org. It is broken. It leaks
> memory, and if memory is correct it can cause the client to core dump.
Also it couldn't possibly be included in core, since it's based on a
GPL'ed UUID library. If you have a more appropiately lice
Jim C. Nasby wrote:
On Wed, Jun 28, 2006 at 01:18:39PM -0400, A.M. wrote:
On Wed, June 28, 2006 1:14 pm, [EMAIL PROTECTED] wrote:
On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
Instead, I would like to humbly request the inclusion of a UUID
datatype (or an op
On Wed, Jun 28, 2006 at 12:38:50PM -0500, Jim C. Nasby wrote:
> On Wed, Jun 28, 2006 at 01:18:39PM -0400, A.M. wrote:
> > On Wed, June 28, 2006 1:14 pm, [EMAIL PROTECTED] wrote:
> > > On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
> > >> Instead, I would like to humbly request the
On Wed, Jun 28, 2006 at 01:18:39PM -0400, A.M. wrote:
> On Wed, June 28, 2006 1:14 pm, [EMAIL PROTECTED] wrote:
> > On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
> >
> >> Instead, I would like to humbly request the inclusion of a UUID
> >> datatype (or an opaque 128 bit datatype)
On Wed, June 28, 2006 1:14 pm, [EMAIL PROTECTED] wrote:
> On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
>
>> Instead, I would like to humbly request the inclusion of a UUID
>> datatype (or an opaque 128 bit datatype) in the core package. It's
>> increasingly common and some datab
On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
> Instead, I would like to humbly request the inclusion of a UUID datatype
> (or an opaque 128 bit datatype) in the core package. It's increasingly
> common and some databases (MS SQLServer) already have built in support for
> it.
On Wed, Jun 28, 2006 at 06:39:16PM +0200, Thomas Hallgren wrote:
> Instead, I would like to humbly request the inclusion of a UUID datatype
> (or an opaque 128 bit datatype) in the core package. It's increasingly
ISTM that we get enough requests for this that it's probably worth
doing.
--
Jim C
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 01:56:47PM +0200, Thomas Hallgren wrote:
A user that is trusted with installing a C-function in the backend is
free to scan the process memory anyway so in what way did that increase
the security? IMHO, the only relevant security in that con
29 matches
Mail list logo
