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 names
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
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 have
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 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
with
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,
Martijn van Oosterhout kleptog@svana.org 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
On Thu, Sep 01, 2005 at 08:50:27AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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
Martijn van Oosterhout kleptog@svana.org 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
Martijn van Oosterhout kleptog@svana.org 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 -
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 is
Martijn van Oosterhout kleptog@svana.org 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
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 an
Martijn van Oosterhout kleptog@svana.org 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
14 matches
Mail list logo
