Thread added to TODO.
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> Hi,
>
> As part of previous discussions about typmod for user type, Tom
> mentioned that you would need to make type and function nam
Martijn van Oosterhout writes:
> On Thu, Sep 01, 2005 at 08:50:27AM -0400, Tom Lane wrote:
>> varchar could do something like using 24 bits for the length
>> and 8 bits for an encoded indication of the charset.
> With the unfortunate effect that strings are limited to 16Mb instead of
> 1Gb.
No,
On Thu, Sep 01, 2005 at 08:50:27AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Simply pass the (Node*) from the parser and let the function sort it
> > out itself. Except now they have to be written in C. Is this
> > unreasonable,
>
> Nope. You're not going to be writing any inte
Martijn van Oosterhout writes:
>TYPMODFUNC =3D function( internal [, sometype ] ) RETURNS int32 or intar=
> ray
> Simply pass the (Node*) from the parser and let the function sort it
> out itself. Except now they have to be written in C. Is this
> unreasonable,
Nope. You're not going to be
On Thu, Sep 01, 2005 at 11:12:26AM +0300, Hannu Krosing wrote:
> Maybe make the last one "WITH CHARACTER SET xxx" and promote WITH to a
> real keyword.
>
> It seems a good idea to have WITH as a real keyword anyway, as at least
> ANSI/ISO syntax for recursive queries seem to require it too.
Sorry
On Thu, Sep 01, 2005 at 11:18:04AM +0200, Dennis Bjorklund wrote:
> String types have 3 modifiers, the length, the charset and the collation.
> The syntax of these are defined by the standard so at least that syntax
> ought to be allowed (even if there are more work to actually do anything
> wit
On Thu, 1 Sep 2005, Martijn van Oosterhout wrote:
> Err, well. My thought was a certain group of type-suffix options would
> be permitted (only zero or one at a time), for example:
>
>WITH TIME ZONE
>WITHOUT TIME ZONE
>CHARACTER SET xxx
String types have 3 modifiers, the length, the
On N, 2005-09-01 at 09:26 +0200, Martijn van Oosterhout wrote:
> On Wed, Aug 31, 2005 at 05:14:13PM -0400, Tom Lane wrote:
> > That strikes me as an unnecessary reduction in flexibility. As long as
> > we make the hardwired type names translate to qualified names (same as
> > they do now) we don't
On Wed, Aug 31, 2005 at 05:14:13PM -0400, Tom Lane wrote:
> That strikes me as an unnecessary reduction in flexibility. As long as
> we make the hardwired type names translate to qualified names (same as
> they do now) we don't have to assume any such thing.
Ack, there's fortunatly only a handful
Martijn van Oosterhout writes:
> I was thinking actually of setting the type searching code to search
> pg_catalog before the normal search_path. The types being hardwired
> into the grammer essentially implied this so I thought I would avoid
> surprises.
That strikes me as an unnecessary reducti
On Wed, Aug 31, 2005 at 02:25:54PM -0400, Tom Lane wrote:
> I still like the idea of pushing the aliasing out of the grammar,
> though. Come to think of it, we could probably even handle the
> multiple-word stuff that way: let the grammar convert CHARACTER VARYING
> to "character varying" and have
Martijn van Oosterhout writes:
> On Wed, Aug 31, 2005 at 11:11:04AM -0400, Tom Lane wrote:
>> One possible approach is to remove the aliasing translation from the
>> grammar altogether, and add a notion of "alias" entries in pg_type that
>> would be found through normal lookup and then replaced by
On Wed, Aug 31, 2005 at 11:11:04AM -0400, Tom Lane wrote:
> IMHO, ideally the aliasing should *only* apply to the built-in types.
> The current hack only approximates this (IIRC, the translation happens
> for any unqualified type name, independently of one's search path).
>
> One possible approach
Martijn van Oosterhout writes:
> My question is, should users be able to create types schema.int4 and
> schema.integer simultaneously. Currently it allows you but it's not
> handled very well (\dT doesn't list both). Should this be allowed?
> Should aliasing for DEC and DECIMAL -> NUMERIC be done
14 matches
Mail list logo
