Re: On hardcoded type aliases and typmod for user types
От | Martijn van Oosterhout |
---|---|
Тема | Re: On hardcoded type aliases and typmod for user types |
Дата | |
Msg-id | 20050901072609.GA28062@svana.org обсуждение исходный текст |
Ответ на | Re: On hardcoded type aliases and typmod for user types (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: On hardcoded type aliases and typmod for user types
(Hannu Krosing <hannu@skype.net>)
Re: On hardcoded type aliases and typmod for user types (Dennis Bjorklund <db@zigo.dhs.org>) Re: On hardcoded type aliases and typmod for user types (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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 of those. > The point about character sets is a bit distressing; here we are > designing a new general-purpose mechanism and we can already see > cases it doesn't handle. Can we fix that? 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 And have the grammer accept these after any type. For example, the type NUMERIC WITH TIME ZONE would be syntactically valid but the code would then reject it. You have a issue then because the typmod function should then be able to return a completely different type because the system looked up "timestamp" and now the function determines that with that option, it should actually be "timestamptz". As for the specific mechanism, well, my options were (in the TYPE declaration statement: TYPMODFUNC = function( intarray [, sometype] ) RETURNS int32 or intarray This restricts the arguments between the brackets to integers, is this reasonable? The sometype would be something to handle the suffix options. (Text pair? option,value). Returning an intarray if a new type is allowed. TYPMODFUNC = function( recordtype [, sometype ] ) RETURNS int32 or intarray The record type could then indicate what's supported, except you can't pass a variable number of arguments (for NUMERIC). How about fill up from the front, leave NULLs for all the unfilled ones. The STRICT flag could tell if all fields need to be filled (ugh). TYPMODFUNC = function( internal [, sometype ] ) RETURNS int32 or intarray 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, it's called fairly early on, all the issues with no valid snapshot apply here and you can't defer the evaluation till later. I'm not sure how to choose, they all handle the current situation fine but what do we want to allow users to do in the future? Is the SQL standard likely to come up with SOMETYPE(ident) as a declaration, in which case we need the second or third options. Ident can be converted to a constant string for these purposes. And then there's output to consider, currently timestamp etc have special cases. But if you're going to allow "CHARACTER SET xxx" to apply to any type, you need a way to reconstruct the values for output. Requireing the user the provide an inverse function is one (possibly unreliable) way. Storing the arguments directly is another. And is one int32 typmod sufficient? This character set per column has been talked about for a while, but where was the information going to be stored? There's several issues to be sorted out yet, I fear. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
В списке pgsql-hackers по дате отправления:
Следующее
От: Hannu KrosingДата:
Сообщение: Re: On hardcoded type aliases and typmod for user types