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
Hi,
As part of previous discussions about typmod for user type, Tom
mentioned that you would need to make type and function names
equivalent. As it turns out, if you refactor a few rules, you can
actually make it work and manage them seperately. For this to work the
current "col_name_keyword" non-
15 matches
Mail list logo
